Unpublish a specific version

[shinnn]

It would be useful if extension authors can unpublish only a single version from Marketplace.

Use case: an author noticed the latest version of their extension includes a serious bug, but cannot find its cause soon. Currently, end users download the broken version until the author fix the bug and publish a new version. If the feature described above is implemented, the author can unpublish the latest one soon and set about bug fix without hurrying.

[joaomoreno]

cc @modigrv

[joaomoreno]

The real solution is is to revert the code changes that caused the issue and release a new bugfix version with those bits.

The rule is always move forward.

[rjmholt]

I think a problem here is accidentally publishing a newer version (e.g. publishing a preview release to a stable extension channel).

If that happens, the versioning scheme is now irreversibly broken and there's nothing extension maintainers can do. Even if we republish the older version afterward, it's not the "latest" version of the package published.

At that point we're forced to break our versioning scheme (which is already constrained by the fact that the marketplace is on semver v1 and npm only accepts semver v2 -- leaving package maintainers with 3 version slots), which is at best very confusing to users.

Naturally everyone tries to take care to make sure that something like this doesn't come to pass, but in software bugs occur, mistakes happen, people are expected to "move fast and break things".

And I'm not saying we should be able to delete published versions, but other package repositories have the ability to delist a specific version so that it is no longer available. Examples:

• NuGet
• PowerShell Gallery

Just want to register this scenario. Happy to open a new issue if need be.

[joaomoreno]

Thoughts, @viradhamMS @pkuma-msft?

[kesane-msft]

@rjmholt I am from the Marketplace team. That's a valid feedback, however we don't get many requests around this. You can always reach to the Marketplace support alias and we will be happy to consider your requests. If we see more and more asks around it we'll consider adding some functionality around it.

[RMacfarlane]

I just ran into the exact situation @rjmholt described, I accidentally released a version of the extension with a much higher version and I’d love the ability to unpublish that so that I can continue with the original versioning scheme.

[sguillia]

I would be happy to unpublish specific versions too.

We are doing beta releases, and we would like to unpublish previous beta versions that are not usable anymore anyway.

We could republish, but we would lose comments, number of installs etc.

[sam-mccall]

+1, hit this today.
We released a new major version for a new feature, hit a problem and "rolled back" by republishing an older version.
So now everyone's getting a major version update with no new feature, which seems at least confusing.

[joaomoreno]

I've forwarded the request to the Marketplace team

[hediet]

If an extension is accidentally published with a minimum required VS Code version that is too low to work, you cannot really fix this anymore.

If you publish a new version of it with an higher required VS Code version, old VS Code versions will ignore it and still use the old buggy extension version.

Without being able to delete certain releases, this cannot be fixed.

[AllanOricil]

I publish a version with a Icon that has copyright and I need to remove it. Luckly no one installed it, but if they had, what would I do?

[hediet]

@AllanOricil I think you can just unpublish your entire extension. Then, you can upload your new version without the infringing icon.

[AllanOricil]

But is there a way to push messages to users to Uninstall it and also remove the folder from ".vscode/extensions"?

[BrunoQuaresma]

I was looking for something like that to update the changelog, is that possible?

[cschlosser]

The lack of this feature can be a huge problem.
This bug microsoft/vscode-vsce#494 lead to my extension being broken for no obvious reason and being unable to unpublish it led to quite a few experiments. Having to reproduce the same environment as on travis doesn't help either.

[xhliu]

This is an important feature we need.

[zhfnjust]

This is an important feature we need！

[joselitofilho]

This is an important feature we need.

[Tyriar]

Could have used this just now, I accidentally published with a bad vscode engine version that relies on a new context key for keybindings. This means I cannot go back and unpublish that - older clients will always receive the "broken version" from now on.

[GonzoLiGGa]

vote for feature!

[caiqichang]

+1

[sfodje]

👍 +1

[dev-Kaustav]

This is a feature we need! I ran into the exact same issie @rjmholt described. I'm a beginner and accidentally published a version with the wrong version name. This feature will help many like me!

[IPcorps]

+1

[philecker]

+1

[prashantvc]

This is in our (Marketplace team) backlog; we are planning to start working on it soon

[up2gx]

This is in our (Marketplace team) backlog; we are planning to start working on it soon

looking forward to this

[yuchien302]

Since default vsce publish takes everything in the folder and uploads it, I just accidentally publish a version that includes my .env file with secrets in it. And I have no way to delete that version.

Seriously, how is deleting a published version still in the backlog for over 5 years now?

[jonaprieto]

Since default vsce publish takes everything in the folder and uploads it, I just accidentally publish a version that includes my .env file with secrets in it. And I have no way to delete that version.

Seriously, how is deleting a published version still in the backlog for over 5 years now?

The best thing to do is probably delete the extension and publish it again. Always remember to check what is included running vsce ls. To ignore files use the file .vscodeignore.

[daalcant]

+1 for this feature.

[jcollard]

+1 for this feature.

[guicaulada]

+1 for this feature

[ArquintL]

I think a problem here is accidentally publishing a newer version (e.g. publishing a preview release to a stable extension channel).

Exactly describes what just happened to me. I've used an older version of HaaLeo/publish-vscode-extension which does not yet support the pre-release flag and thus happily published my pre-release as a stable release to the marketplace.

Having fun times here creating another fake stable release to fix the issue by bumping just the version number

[melMass]

I think a problem here is accidentally publishing a newer version (e.g. publishing a preview release to a stable extension channel).

I just ran into that too 😅, unrelated but it's strange that it's a cli arg that defines that and not something in the package.json next to your version...

[ArquintL]

I think a problem here is accidentally publishing a newer version (e.g. publishing a preview release to a stable extension channel).

Exactly describes what just happened to me. I've used an older version of HaaLeo/publish-vscode-extension which does not yet support the pre-release flag and thus happily published my pre-release as a stable release to the marketplace.

Having fun times here creating another fake stable release to fix the issue by bumping just the version number

I found out afterwards that everything would have worked in the first place because it does not matter whether you set the pre-release flag or not if the extension has already been bundled.
The fact that the VSCode backend (namely https://marketplace.visualstudio.com/manage/publishers/<publisher>/extensions/<extension>/hub?_a=manageExtension) and the VSCode Marketplace when opened in the browser do not distinguish at all between pre-releases and non-pre-releases added to the confusion. In particular, I thought I've published a stable instead of a pre-release and then had to bump all version numbers to fix this issue even though the VSIX's extension.vsixmanifest file would have correctly specified that it's a pre-release.

[melMass]

Just an fiy:
So I published a release by mistake (while the extension only used prereleases until then), I then unpublished it (which removed the extension and all past versions all together 😅)

Upon republishing a pre-release It seems like there are two distinct items now in the extensions list (the marketplace does show the right info)

So now there are two extension with the same name and ID. Not sure how to debug that properly or if will just get garbage collected at some point?

[zimmski]

Read the whole issue and i can provide two experiences that are new and critical to us:

• a. Happened now twice that we introduced a security issue (happens to the best of us) that were introduced, realized, and then fixed after a very short time (one in about 9h and one in 2h)
• b. Happened now trice (today is one of them) where we released a version that broke either a functionality for all users somehow or for a very specific functionality (e.g. only MacOS users on ARM64)

No matter how fast we are fixing these issues, we still have to wait for the CI to give the OK and then the CD to give the OK. And no matter how long that is, it is far too long when you know that version X to Y are affected and could be just deleted. This is what we do with the JetBrains marketplace btw and with the artifacts that we control ourselves. The only exception is the VS Code marketplace. Which is in my opinion very cool to work with, except for this single feature that is missing.

This missing feature is especially annoying since we are releasing right to the user with every merge. That is usually really cool, but in the 5 cases above, it wasn't. We adapted our CI to catch those cases, but as you all surely know all to well, bugs happen and we might need to remove a published version once again. Removing the whole extension is not an option and pushing a new version isn't either for the reasons i stated.

[Mailaender]

Why do you call it manage extensions when there is nothing to change?

vsce unpublish 2.0.0
This will delete ALL published versions! Please type '2.0' to confirm: no

O.o

[tooltitude-support]

Any news on this?

[ctjlewis]

We need the ability to unpublish versions, the same way NPM allows it.

[Jonak-Adipta-Kalita]

Its still an issue....? its been 6 years.....

[renweibo]

Any update？

[AlexPapageorge-Poly]

I would like to unpublish a version as well. Has there been any update on how to do this?

[tooltitude-support]

It looks like the API used by vsce (extension publishing tool) has a method to delete the extension. Unfortunately, it didn't work in naive way, it failed with error code 400.

Read more here: microsoft/vscode-vsce#909

P.S. @seaniyer is it possible that someone from your team takes a look at it? If this command works, then this problem is essentially solved, and marketplace support team won't need to delete extension versions manually. 400 points out to the fact that it's implemented but doesn't work for some reason.

[seaniyer]

Unpublishing a specific version is currently not supported for VS Marketplace.
@xavierdecoster any thoughts regarding that API ?

[tooltitude-support]

@seaniyer That's actually the main reason for my investigation. If there's an easy way to support it via the official API, then this problem could be solved for a lot of folks. The 400 error code points out that it's implemented but doesn't work due to some misconfiguration of the API.

[zimmski]

@kesane-msft since you wrote that you need more people asking about this feature. How many do you need? There are now about 100 likes on the issue.

We just hit again a bug where we would like to unpublish a version. We can for all platforms except for VSC see
#235 (comment) for some description on why that is useful to everyone.

[seaniyer]

Hi folks,

Solution proposal for unpublish version & Request for feedback

VS Marketplace team is looking to invest in this popular feature request in the coming months. I would like to kick things off by sharing an initial draft of Unpublish specific version - Solution proposal PR for everyone’s input. The document also has a summary of problem scenarios as we understand them so far. I would like to make sure the proposal is starting off in the right direction and no important problem scenarios are missed. Please review and comment in the PR. Thanks for your contributions!

cc: @mariaghiondea @joaomoreno @isidorn @lyndaidaii @sbanni