📎 Publish nightlies as pre-releases instead of separate extension
Closed this issue · 4 comments
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
- Stop packaging nightly
- Stop publishing nightly
- Mark pre-releases with
vsce - Refactor code meant to prevent conflicts with nightly
- Use CI to ensure the version pattern matches the corresponding channel
- Use CI to ensure stable version numbers are always higher than the version of the latest pre-release
Nice!
Are you sure to go for
major.EVEN_NUMBER.patchfor stable release andmajor.ODD_NUMBER.patchfor pre-release way
instead of
Non-linear
patchfor stable release
?
References
Nice!
Are you sure going into
major.EVEN_NUMBER.patchfor stable release andmajor.ODD_NUMBER.patchfor pre-release wayinstead of
Non-linear
patchfor stable release?
References
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.
We might even contemplate the
YYYY.M.NNNNversioning 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 microsoft/vscode-vsce#932 which has been announced to be on the way.
We might even contemplate the
YYYY.M.DDHHversioning scheme for nightliesThat 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.