Improvement: Publish pre-release version of lldb-dap extension for vscode

[mateusz-plociennik]

I would like to see the latest (HEAD) version of the extension being published as pre-release.

[llvmbot]

@llvm/issue-subscribers-lldb-dap

Author: Mateusz Płóciennik (mateusz-plociennik)

I would like to see the latest (HEAD) version of [the extension](https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.lldb-dap) being published as pre-release.

[JDevlieghere]

A release is always HEAD at the time, but I like the idea of going through pre-releases. I'll see what that requires.

[JDevlieghere]

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

1. Publishing a pre-release requires bumping the version
2. Publishing a release requires bumping the version (i.e. you can't promote a pre-release to a full release)
3. You cannot publish something with a suffix (for example I tried publishing 0.2.17-20250924 as today's nightly)

The documentation suggests using major.EVEN_NUMBER.patch for release versions and major.ODD_NUMBER.patch for pre-release versions. My primary hesitation with something like that is that currently the https://github.com/llvm/vscode-lldb repo is a mirror and I'd rather not subtly diverge the version number in that repo.

One potential solution is that we change the version number in llvm-project to 0.0.0 and manage the version number in the vscode-lldb repo. That requires us to communally agree to not touch that to avoid merge conflicts. We could create automation to tag major release that bump the minor version to the next even number and automation that every night bumps the patch version on the next odd number.

[walter-erquinigo]

One potential solution is that we change the version number in llvm-project to 0.0.0 and manage the version number in the vscode-lldb repo. That requires us to communally agree to not touch that to avoid merge conflicts. We could create automation to tag major release that bump the minor version to the next even number and automation that every night bumps the patch version on the next odd number.

I did something similar for another extension that I managed. main had 0.0.0 for the version, and I had a script create a new branch with the correct version for the disitrubtion channel. We had two channels: one for the nightly release of our SDK and one for the stable release. It was very manageable for sure.

[JDevlieghere]

I asked @matthewbastien how they handle this for the Swift extension and he told me that they follow the suggested versioning scheme and always bump the minor version to the next odd number for nightlies. That seems like a great idea, so I'll put something together that does that. We shipped a regression today (0.2.17) that could have been caught by someone living on a nightly so that helped bump the priority for this.

[JDevlieghere]

I added a github action that publishes a pre-release version every day at 10AM PST: https://github.com/llvm/vscode-lldb/blob/main/.github/workflows/pre-publish.yml. It bumps the minor version to the next odd number and uses the date as teh patch version. The first pre-release version is (0.3.20250925) is available in the marketplace.