Support semantic version pre-release tags for extensions

[felipecrs]

Pre-releases are now supported, but they require a non-pre-release semantic version.

The official docs says that support for this will arrive in the future, and therefore I'm opening this issue for tracking its progress.

It's worth mentioning that https://github.com/microsoft/vscode-vsce/issues/148 is basically about the same thing, but things are different as vsce supports pre-release of extensions now (despite not in its version identifier).

This is a requirement for allowing the semantic-release-vsce plugin support pre-release channels the same way semantic-release supports it in npm as well (https://github.com/felipecrs/semantic-release-vsce/issues/192).

[PEZ]

I just bumped into this limitation as well. We're using <branch>-<short-commit-is> for pre-releases, but the marketplace refuses to accept it.

[GitMensch]

I'm still wondering why the feature was shipped in vscode in 2021 but other than the note that this will be supported in the future:

We only support major.minor.patch for extension versions and semver pre-release tags are not supported. [...] Full semver support will arrive in the future.

there's also a suggested workaround in the very same place (increment the minor version for a pre-release and the patch for newer pre-releases, then increment the minor version again when the pre-release "is completed"):

we recommend that extensions use major.EVEN_NUMBER.patch for release versions and major.ODD_NUMBER.patch for pre-release versions. For example: 0.2. for release and 0.3. for pre-release.

@seaniyer Do you have an option to discuss improving the situation about the missing semver pre-release tag support with the marketplace team?

[seaniyer]

@GitMensch

Happy to discuss this. I saw your issue here but wanted some more info: https://github.com/eclipse-che4z/che-che4z-lsp-for-cobol/issues/1913 Can you detail the problem you are encountering in publishing pre-release versions of the extension? A use case or example would be great to help us understand.

[GitMensch]

We can do

vsce package --pre-release
vsce publish --pre-release

but we cannot use semver prerelease labels as the marketplace does not support that.

If it is supported then we can publish prerelease versions without an artificial increase of the version, we prepare for 1.0 so have a prerelease for that and once this is finished we release 1.0. From the semver version link:

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

If we currently want to do that we need

1.0.0 < 1.0.1 < 1.0.2 < 1.0.3 < 1.0.4 < 1.0.5 < 1.0.6 < 1.0.7 (or more likely with all those numbers: 1.1.0)

And if you combine that with Changelogs for each patch level, you also get a huge changelog file.

With full semver support, as promised to "be available later" (I think that promise will be soon 2 years old) we can stay with the same number (and a single changelog paragraph as the version does not increase as the new one is "unreleased" / in preview and is adjusted as needed.

[seaniyer]

I want to make sure I understand the root problem we are trying to solve here (by enabling semver). Why is incrementing the version number (patch, or minor) for publishing pre-releases an issue? Just that it causes a long changelog? There might be more that's not clear yet. I'm happy to jump on a call and chat about this.

[GitMensch]

The point of a preview is a pre-release. You don't increment the version number - apart from the label, which is ordered alphabetically.

Full SemVer support was the original promise, too.

[thisdotmatt]

From my understanding, it seems that semantic versioning is still not supported. Is this correct?