This looks fantastic! Thank you so much for getting this on the agenda.

My only concern with the spec as it stands at the moment is the two points about how unpublishing all the versions should have the same behavior as the current unpublish action. I guess there are two conflicting use cases here.

1. User unpublishes all current published versions, but still intends to publish a new version of the same extension.
2. User intends to delete the extension altogether.

Right now the unpublish behavior assumes case 2. The problem with case 2 - as I have painfully discovered when I accidentally blew away an extension with thousands of installs - is that even if you republish again with the exact same name and marketplace token, existing users of that extension cannot upgrade, because it's considered an entirely new extension.

On one hand, this behavior is good, because it means if someone unpublishes an extension then a bad actor can't come along and hijack the namespace without the existing users explicitly uninstalling and reinstalling that extension. On the other hand, for the legitimate scenario as described in case 1, above, this leaves a potentially large number of users stuck on broken or out of date versions.

If unpublishing versions and removing extensions were two separate operations, this situation could be avoided.

Thanks again for taking a look at this.

Looks really great! Thank you!

I would add one more important use case: You want to remove a really old version to reduce support burden on the publisher. So, I would avoid putting 1K download limit.

This looks great, apart from the wording restricting it to VS Code extensions. The VS Marketplace also provides extensions for Visual Studio and Azure DevOps, who would also greatly benefit from this. Is there any possibility of including the three types of extensions rather than restricting it? The original issue does not state the purpose was solely for VS Code.

Related on SO: I've published a wrong version number to VSCode marketplace. Best way to handle/downgrade version number?

What would happen for users who already installed a version which subsequently gets unpublished? Would VS Code automatically rollback / upgrade (if available)? (related)

This looks great, apart from the wording restricting it to VS Code extensions. The VS Marketplace also provides extensions for Visual Studio and Azure DevOps, who would also greatly benefit from this. Is there any possibility of including the three types of extensions rather than restricting it? The original issue does not state the purpose was solely for VS Code.

@alexangas Good question! Version history is only supported for VS Code extensions. For example, in case of VS only the latest extension version (not referring to VS version) can be installed. That's the reason behind Unpublishing a specific version being scoped to VS Code at this time.

Related on SO: I've published a wrong version number to VSCode marketplace. Best way to handle/downgrade version number?

What would happen for users who already installed a version which subsequently gets unpublished? Would VS Code automatically rollback / upgrade (if available)? (related)

FYI @isidorn @sandy081 @joaomoreno

This looks fantastic! Thank you so much for getting this on the agenda.

My only concern with the spec as it stands at the moment is the two points about how unpublishing all the versions should have the same behavior as the current unpublish action. I guess there are two conflicting use cases here.

1. User unpublishes all current published versions, but still intends to publish a new version of the same extension.
2. User intends to delete the extension altogether.

Right now the unpublish behavior assumes case 2. The problem with case 2 - as I have painfully discovered when I accidentally blew away an extension with thousands of installs - is that even if you republish again with the exact same name and marketplace token, existing users of that extension cannot upgrade, because it's considered an entirely new extension.

On one hand, this behavior is good, because it means if someone unpublishes an extension then a bad actor can't come along and hijack the namespace without the existing users explicitly uninstalling and reinstalling that extension. On the other hand, for the legitimate scenario as described in case 1, above, this leaves a potentially large number of users stuck on broken or out of date versions.

If unpublishing versions and removing extensions were two separate operations, this situation could be avoided.

Thanks again for taking a look at this.

Solution proposal updated to reflect # 1. Good call out!

@seaniyer Sandeep and me just discussed this and overall this makes good sense from the VS Code point of view, and we are excited about Marketplace picking this one up.

The only open question is the one Sandeep raised - what should VS Code do when the a specific version is unpublished, if that version is being used by the user.

• After discussing with Sandeep, we believe that VS Code needs to react and downgrade the user to the highest unpublished version. We can discuss if Marketplace needs to update the current query that returns a list of versions (to specify if a version has been unpublished), or if VS Code should figure this out by making some assumptions (seeing that the latest available version from MP is lower than the current running extension version).
• Also what if the last version is unpublished - than your assumption is that the whole extensions gets unpublished. How would client react to that? We propose to do the same thing we do today when the whole extension gets unpublished, and that is a no-op. Leave the extension running, but we might need to notify the user.

@sandy081 let me know if I missed something from our discussion. Thank you

@seaniyer Sandeep and me just discussed this and overall this makes good sense from the VS Code point of view, and we are excited about Marketplace picking this one up.

The only open question is the one Sandeep raised - what should VS Code do when the a specific version is unpublished, if that version is being used by the user.

• After discussing with Sandeep, we believe that VS Code needs to react and downgrade the user to the highest unpublished version. We can discuss if Marketplace needs to update the current query that returns a list of versions (to specify if a version has been unpublished), or if VS Code should figure this out by making some assumptions (seeing that the latest available version from MP is lower than the current running extension version).
• Also what if the last version is unpublished - than your assumption is that the whole extensions gets unpublished. How would client react to that? We propose to do the same thing we do today when the whole extension gets unpublished, and that is a no-op. Leave the extension running, but we might need to notify the user.

@sandy081 let me know if I missed something from our discussion. Thank you

@isidorn @sandy081
After discussing with @sbanni and @lyndaidaii on the Marketplace team, we are in agreement with these two proposed approaches on VS Code side:

• VS Code needs to react and downgrade the user to the highest unpublished version
• no-op on the client side when all versions have been unpublished (same as the whole extension is unpublished)
  We are going to investigate updating the API to return a list of versions with unpublished/published marked.

Thanks also to @starball5 for raising the same client-side questions.

This is awesome. Can some visibility be shared on will this be done?