Deprecate biomejs.biome-nightly in favor of pre-release versions of biomejs.biome

[Malix-Labs]

Deprecate biomejs.biome-nightly in favor of pre-release versions of biomejs.biome

Documentation

• https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

[nhedger]

There is an added overhead that I'm not particularly a fan of, which made me go the current way in the first place.

The marketplace does not support semver, so we'd have to start using major.EVEN_NUMBER.patch for release versions and major.ODD_NUMBER.patch for pre-release versions. Additionally, we'd always have to release both a pre-release version followed by a release version so that users of a pre-release version are not automatically updated to the release version.

I'm not against exploring the idea again, but I'd like to understand what benefits we'd gain from doing so because I feel this would make the deployment process more complicated than I think it needs to be.

[Malix-Labs]

we'd have to start using major.EVEN_NUMBER.patch for release versions and major.ODD_NUMBER.patch for pre-release versions
Additionally, we'd always have to release both a pre-release version followed by a release version so that users of a pre-release version are not automatically updated to the release version.

(Source of that recommendation for reference)

The non-support (yet) of full semver is a notoriously controversial API behavior among VSCode extension developers;
And the recommendation to use major.EVEN_NUMBER.patch and major.ODD_NUMBER.patch is also controversial as quite non-standard.

I think users being updated to the release version is not a problem, as they would still be updated to the next pre-release version when released.
Thus, using the regular major.minor.patch semver would theoretically be the most standard and simple solution.
Note that it would then makes the stable release to have non-linear semver (1.0.0 -> 1.0.5 would be the direct update while not being linear)
Which I'd say is the standard to do major.minor.patch semver with internals defining stable/pre-release

The main benefit users would have is that the extension would semantically be the same (with versions diff).
Thus, settings would not be duplicated, it would not be possible to enable both versions at the same time, it's easier for users to go back to an anterior version (pre-released or not) that way, and the installation count would be summed up instead of split.

The trade-off is about using non-linear patch semver for the stable release until VSCode feats pre-release semver.

[nhedger]

I think users being updated to the release version is not a problem, as they would still be updated to the next pre-release version when released.

Fair enough

Thus, using the regular major.minor.patch semver would theoretically be the most standard and simple solution.
Note that it would then makes the stable release to have non-linear semver (1.0.0 -> 1.0.5 would be the direct update while not being linear)
Which is done usually by fast release cycle projects

Not the end of the world, I guess. Do you happen to know of an extension that does it like that? I'd love to know more.

[Malix-Labs]

Do you happen to know of an extension that does it like that? I'd love to know more

I don't know which "standard" most extensions prefers to choose, between:

• major.EVEN_NUMBER.patch for stable release and major.ODD_NUMBER.patch for pre-release
• Non-linear patch for stable release

However, I can certainly tell you that if they chose the first, it's very much probably because VSCode Docs told them too
Which I personally find to be a bad advice. (see microsoft/vscode-vsce#932)

To counter that, devs that found it to be weird, such as you (and me also to be honest) usually just prefers to not use the native pre-release feature and publish another extension for their pre-release (which biomejs.biome-nightly is).

See microsoft/vscode-vsce#932

[ematipico]

FYI, I've always preferred one extension with pre-releases instead of two extensions. Once you set up the CI right, it's done and you don't have to worry about it anymore.

Having two extensions has more clerical work: tokens, reviews, out-of-sync, etc.

[Malix-Labs]

True, me too;
But there is a tradeoff for maintainers, as you can see in microsoft/vscode-vsce#932

[ematipico]

Yeah, the fact that they don't support semver 2 is a huge downside

[Malix-Labs]

And outstandingly weird they chose not to do what I suggested in microsoft/vscode-vsce#932 in the first place tbh, it seemed obv

[nhedger]

As I said, I'm willing to give it another go.

I'll draft something in the coming days.

[nhedger]

#137