📎 Publish nightlies as pre-releases instead of separate extension

[nhedger]

Summary

The stable and nightly versions of Biome are currently published as two separate extensions.

• biomejs.biome (stable)
• biomejs.biome-nightly (nightly)

One of the goals of publishing a nightly release of the extension is to allow early adopters to test new features and help us catch issues before they land in a stable release. In order to reduce friction, switching from the stable release to the nightly and vice-versa should be as straightforward as possible.

When I originally petitioned to split both releases into separate extensions, my hope was to avoid dealing with the fact that the VS Marketplace does not support SemVer. To cope with that limitation, extensions that publish pre-releases usually have a system in place that consists of publishing stable releases with an even-numbered minor version and pre-releases with an odd-numbered minor version.

• 2.0.0 (stable)
• 2.1.0 (pre-release)
• 2.2.0 (stable)

This has the effect of producing non-linear versions within a channel (2.0.0 -> 2.2.0), which is something I'm admittedly not a fan of. That being said, and having discussed it among ourselves and with community members, we feel that the benefits of having a single extension with two release channels outweigh the cons.

• Easier to switch between stable and nightly
• Users need to maintain only one set of settings
• Easier upgrade path
• No more conflicts between both versions

Upgrade paths

• Users who subscribe to the stable release channel expect to be upgraded to the next stable version, not the next pre-release version.
• Users who subscribe to the pre-release channel expect to be upgraded to the next pre-release version, but won't mind being upgraded to the next stable release if there isn't yet a pre-release version available.

Version numbers

To prevent confusion, the version number of the latest stable release should always be higher than the latest pre-release, even if this means that we end up with gaps.

For example, if we publish a pre-release (2.1.0), and some days later we publish another pre-release (2.3.0), the next stable release should not be 2.2.0, but 2.4.0.

To do

• [x] Stop packaging nightly
• [x] Stop publishing nightly
• [x] Mark pre-releases with vsce
• [x] Refactor code meant to prevent conflicts with nightly
• [x] Use CI to ensure the version pattern matches the corresponding channel
• [x] Use CI to ensure stable version numbers are always higher than the version of the latest pre-release

[Malix-Labs]

Nice!

Are you sure to go for

major.EVEN_NUMBER.patch for stable release and major.ODD_NUMBER.patch for pre-release way

instead of

Non-linear patch for stable release

?

References

• https://github.com/biomejs/biome-vscode/discussions/123#discussioncomment-8427312
• https://github.com/microsoft/vscode-vsce/issues/932

[nhedger]

Nice!

Are you sure going into

major.EVEN_NUMBER.patch for stable release and major.ODD_NUMBER.patch for pre-release way

instead of

Non-linear patch for stable release

?

References

• Deprecate biomejs.biome-nightly in favor of pre-release versions of biomejs.biome #123 (reply in thread)
• Full Semver Standard Support microsoft/vscode-vsce#932

Not sure yet.

We might even contemplate the YYYY.M.NNNN versioning scheme for nightlies. That's what GitLens does. Doing so would keep the stable releases linear.

[Malix-Labs]

We might even contemplate the YYYY.M.NNNN versioning scheme for nightlies

That would require having also the versioning for pre-release to be locked into this non-semver versioning forever, thus could never profit from https://github.com/microsoft/vscode-vsce/issues/932 which has been announced to be on the way.

[nhedger]

We might even contemplate the YYYY.M.DDHH versioning scheme for nightlies

That would require having also the versioning for pre-release to be locked into this non-semver versioning forever.

True. I’ll keep it in mind.