Versioning of the Air Code extension

[DavisVaughan]

VS Code recommends a super weird versioning strategy if you plan to have release and pre-release versions of your extension
https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

We only support major.minor.patch for extension versions, semver pre-release tags are not supported. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future.

VS Code will automatically update extensions to the highest version available, so even if a user opted-into a pre-release version and there is an extension release with a higher version, the user will be updated to the released version. So, 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.

If extension authors do not want their pre-release users to be updated to the release version, we recommend always incrementing and publishing a new pre-release version before publishing a release version to make sure that the pre-release version is always higher. Note that while pre-release users will be updated to a release version if it is higher, they still remain eligible to automatically update to future pre-releases with higher version numbers than the release version.

---

I think we may consider using a pre-release version if we want to send out an experimental feature? I doubt we'd set up nightly releases because that's probably too easy to break.

Ruff uses a calendar-ish based versioning scheme that seems reasonable:

• We'd start with 2025.0.0 and every release we bump to the next even minor version, so 2025.2.0
• Every year we bump the major version, so 2026.0.0 at the start of next year
• We don't use the patch version at all and just keep it 0 (unless we really need it)
• In the rare case where we may want a pre-release, we'd release an odd numbered minor version, so 2025.3.0 for example

I don't think the extension version matters that much in terms of semver, that's more important for the executable version, so I vote we just stick with this approach even though it's weird, since it seems to follow vs code recommendations

[lionel-]

So the main distinction between pre-release and release versions is that only the latter are published to the marketplace? And that's what prevents users of even versions to be upated automatically to odd versions?

If that's the case I don't understand:

VS Code will automatically update extensions to the highest version available, so even if a user opted-into a pre-release version and there is an extension release with a higher version, the user will be updated to the released version. So, 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.

How does VS Code know not to upgrade 0.1.0 to 0.2.0 if 0.3.0 is not pushed to the marketplace?

That said it seems like it's a good thing that users who installed a pre-release manually automatically get updated to the latest release and don't get stuck with the pre-release.

[DavisVaughan]

Pre-releases are definitely published to the marketplace

[DavisVaughan]

We settled on:

• Keeping the major version of the extension in sync with the major version of the cli
• The minor version of the extension is:
  • Even for standard releases
  • Odd for pre-releases
  • This means you typically bump the extension by 2 minor versions between releases
• The patch version of the extension can be used for extremely small bug fixes, but generally prefer bumping the minor version
• The minor and patch versions of the extension do not stay in sync with the cli version