Adopt the pre-release extension feature

[isidorn]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.

Summary

Refs: microsoft/vscode#15756

VS Code now supports pre-release extensions. Docs that should help: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

I know powershell has a separate powershell preview extension. Ideally we would deprecate that extension and you would publish pre-release versions. VS Code can migrate your users automatically once you do the adoption.

Let me know what you think.

fyi @TylerLeonhardt

Proposed Design

No response

[andyleejordan]

We've got this on our radar, but question for you @isidorn: I know VS Code now supports this, but isn't the marketplace still working on full support (especially around supporting extensions to publish with proper semantic versioning, with the necessary pre-release suffixes)? I looked and can't find the issue for the latter, but it's a long open one.

[isidorn]

@andschwa yes, MP is working on supporting full semver versioning. However since the MP is currently in the process of changing their backend infrastructure this will probably take some time. My very very rough estimate, end of 2022 at the earliest.
Here's the issue on the MP side microsoft/vsmarketplace#50

[andyleejordan]

Cool, thanks! I'll keep an eye on that and when this is fully supported we'd love to do it.

[JustinGrote]

@andschwa why is microsoft/vsmarketplace#50 a blocker for us? At least since the updated CI and the CalVer versioning, we don't use any semver suffixes in the published packages, and we only use 3 octets so if you wanted to clearly distinguish Preview from stable, the fourth octet could be used e.g. 2022.02.0.4

[andyleejordan]

We use -preview suffix for the preview releases, and that's explicitly what marks them as newer (and not stable), and is what their implementation seems to require as well.

[JustinGrote]

@andschwa I'm confused

When publishing the vsix why can't you just either append an extra .0/.1 or remove the preview flag on the filename when publishing?

EDIT: Nevermind, reading
https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

Makes this difficult for calver, because newer versions will bump prerelease people to stable regardless, making it difficult to maintain two long-term tracks. Crappy implementation if you ask me, there should be an option to always stay on pre-release if it is tagged that way.

[JustinGrote]

@andschwa I did some more thinking on this, why not just append .1 as the forth octet to every preview release? Then just have to make sure a preview always goes out with the stable on releases (which they do today)

For instance:

2022.02.1.1 - Prerelease
2022.02.1 - Stable

2022.02.2.1 - Prerelease
2022.02.2 - Stable

2022.03.0.1 - Prerelease
2022.03.0 - Stable

etc.

[TylerLeonhardt]

Unfortunately, I don't think npm likes that forth octet :( it's really annoying... any the marketplace doesn't support -blah

[JustinGrote]

@TylerLeonhardt right, just trying to think of a workaround for the prerelease tag.

[andyleejordan]

@SydneyhSmith Assigned to you for investigation!

[andyleejordan]

I'm pretty sure the versioning issue is sorted out since we no longer maintain two long separate tracks. We really have one extension, and the preview is just exactly that, an early preview of what's planned to go into the stable extension as long at isn't broken. So we don't need full SemVer support any more, and can just use our existing versions like 2023.3.0 with preview: true in the package.json (and --pre-release for vsce when packaging and publishing). Additionally it'll be absolutely fine that when we roll preview to stable (just by switching to preview: false) that preview users will get the stable installed...it will technically be the newest, and the docs say those users will get the next preview when we push it. So we're on our way to supporting this!

[JustinGrote]

Makes sense to me! Upon release you'll probably need to push one last preview extension that implements the deprecated field and points to the "main" extension.

[isidorn]

Awesome! Love seeing this ❤️

We have a mechanism in VS Code for transitioning existing users of "PowerShell Preview" to the new "PowerShell Pre-Release". Sydney and me are discussing to enable this.

[andyleejordan]

@JustinGrote I don't see any deprecated field in the extension manifest, but I believe that @isidorn and the VS Code team are handling this in the backend. Thanks very much all!

FYI @TylerLeonhardt I need to update the docs, but we actually need to keep preview: true in the manifest for our pre-release versions because it's the way we determine during packaging and releasing that we need to pass --pre-release to vsce. Since we have to drop the -preview suffix from the version, there doesn't seem to be any other good way to determine from the sources (well, unless we check the changelog but that's hairier) if it's a pre-release version. So, that's why the flag is staying!

[JustinGrote]

@JustinGrote I don't see any deprecated field in the extension manifest, but I believe that @isidorn and the VS Code team are handling this in the backend. Thanks very much all!

Oops you are right, this is a backend thing
microsoft/vscode-discussions#1

[TylerLeonhardt]

@andschwa could change the preview: false right before the publish in the build?

[andyleejordan]

I don't think so, it's embedded in the VSIX isn't it? So it's already been created and signed. It'd be a heck of a hack to unzip it, edit the package.json and rezip it (and that might break whatever the signing is) just to avoid a little "preview" banner.

[TylerLeonhardt]

Oh do you unzip the VSIX in order to check the preview property of the manifest?

[andyleejordan]

No, I check it from the sources that exist next to it in the pipeline (from the ADO checkout step). But to change it "right before the publish" as you suggest would entail editing the VSIX, no? Since vsce takes a --package-path to the VSIX file?

Anyway, we do need to revisit it because it appears that the marketplace web page like here shows the assets from the most recent release (even if it was "pre-release") meaning that page shows the "preview" tag and the "preview" icon (which only exist in the pre-release version of the extension). Is this perhaps something that could be fixed upstream? I.e. code the marketplace webpage to display information from the most recent non-pre-release upload? The "version" and "last updated" on the side also are from the pre-release upload, not the stable one.

[TylerLeonhardt]

No, I check it from the sources that exist next to it in the pipeline (from the ADO checkout step). But to change it "right before the publish" as you suggest would entail editing the VSIX, no? Since vsce takes a --package-path to the VSIX file?

In this case, maybe set it to false before packing the VSIX and then set it back to true... or just use an Azure DevOps pipeline variable that you could read later.

I'll defer to @isidorn for the Marketplace bug.

[isidorn]

I acknowledge this bug on the Marketplace side.
For this to be fixed either Marketplace has to be aware of pre-release extensions or to introduce SemVer support. I do not think either will happen this year, but hopefully some time in 2024.

My suggestion - consider just removing the "preview" tag in both cases.

[andyleejordan]

All right, all right. I'll find another way to pass the pre-release info along from build to package to publish, and will temporarily stop changing the icon to the PowerShell Preview icon (but it's so cute).