Let the tag choose whether the extension is a pre-release - #4
Merged
Conversation
`vscode-v0.0.2` publishes a stable release; `vscode-v0.0.2-pre` publishes a pre-release of the same version. VS Code keeps users on the newest stable build unless they opt that extension into the pre-release channel, so this is how a build reaches willing testers without being pushed at everyone. The suffix has to live on the tag: VS Code extension versions must stay major.minor.patch, so a pre-release is not a different version string but a property inside the package. That property is written by `vsce package --pre-release`, and vsce refuses to publish a package as a pre-release unless it was built as one: Cannot use '--pre-release' flag with a package that was not packaged as pre-release. Please package it using the '--pre-release' flag and publish again. Which means the choice belongs at build time, and the tag has to drive the whole chain rather than only the final publish call: - package.json gains a `package:pre-release` script. A sibling script rather than shell interpolation inside the existing one, which would not work under cmd.exe. - vscode-extension/pom.xml selects it through a `vsce.package.script` property. - scripts/build-test-release gains `--extension-pre-release`, which sets that property. - build.yml gains an `extension-pre-release` input mapped onto the flag. - release-vscode.yml parses the `-pre` suffix, passes it down, adds `--pre-release` to both `vsce publish` and `ovsx publish`, and marks the GitHub Release as a prerelease. Before publishing, the workflow re-reads the built VSIX manifest and fails if the marker disagrees with the tag, so the two cannot drift: vsce would reject one direction, and the other would quietly ship a pre-release as stable. Verified end to end locally: the flag reaches `npm run package:pre-release` and produces `Microsoft.VisualStudio.Code.PreRelease" Value="true"` in the manifest, while a default build has no marker. Tag parsing accepts `vscode-v0.0.2` and `vscode-v0.0.2-pre`, and rejects a wrong version or an unrecognized suffix rather than treating it as stable. Documented in RELEASING.md and vscode-extension/AGENTS.md. Also carries the icon you added, which registers as Icons.Default in the VSIX with the SVG source excluded.
Language server, osate-cli and the VS Code extension were at three unrelated versions (1.0.0-SNAPSHOT, 0.1.3, 0.0.2). Nothing has been tagged or released yet, so the CLI moving down from 0.1.3 affects no published artifact. The language server keeps the Tycho development form, 0.1.0-SNAPSHOT paired with Bundle-Version 0.1.0.qualifier, so each build still stamps a timestamp and p2 can tell rebuilds apart. Tycho requires the pom and manifest versions to agree, so both manifests moved with the poms. Releasing ls-v0.1.0 still means dropping -SNAPSHOT first, which release-server.yml already enforces. The root aggregator moved to 0.1.0-SNAPSHOT as well. It ships nothing, but it is what build-provenance.properties records as tooling.version, which would otherwise report 1.0.0-SNAPSHOT for a build of three 0.1.0 components. Its parent reference in vscode-extension/pom.xml moved with it. The extension version was bumped with `npm version` so package.json and package-lock.json stay in step, and CHANGELOG.md promotes [Unreleased] to [0.1.0]. The RELEASING.md tag examples now use the real versions. Verified by a full build rather than inspection, since Tycho rejects a pom and manifest that disagree: language server 0.1.0 with 35 tests, extension 0.1.0, CLI 0.1.0, and all five test-count assertions passing. The artifacts carry it through — org.osate.aadl.ls_0.1.0.v20260902-1313.jar, aadl2-0.1.0.vsix, `osate-cli --version` reporting 0.1.0, and provenance recording tooling.version=0.1.0-SNAPSHOT with cli.version=0.1.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
vscode-v0.0.2publishes a stable release;vscode-v0.0.2-prepublishes a pre-release of the same version.Why the suffix goes on the tag, and why it can't be publish-time only
VS Code extension versions must stay
major.minor.patch, so a pre-release isn't a different version string — it's a property recorded inside the package. That property is written byvsce package --pre-release, andvsce publishrefuses to add it afterwards:I found that in
@vscode/vsce/out/publish.jsbefore wiring anything, which is what determined the design: the decision belongs at build time, so the tag has to drive the whole chain rather than just the final publish call.package.jsonpackage:pre-releasescript — a sibling script, not shell interpolation in the existing one, which wouldn't work undercmd.exevscode-extension/pom.xmlvsce.package.scriptpropertyscripts/build-test-release--extension-pre-releasesets that propertybuild.ymlextension-pre-releaseinput mapped onto the flagrelease-vscode.yml-pre, passes it down, adds--pre-releaseto bothvsce publishandovsx publish, marks the GitHub Release as prereleaseBefore publishing, the workflow re-reads the built VSIX manifest and fails if the marker disagrees with the tag. Without that check the two could drift: vsce rejects one direction loudly, but the other would quietly ship a pre-release as stable.
Verified locally
npm run package:pre-releaseand producesMicrosoft.VisualStudio.Code.PreRelease" Value="true"in the manifest; a default build has no marker (checked both directions, so the flag can't leak).vscode-v0.0.2→ stable,vscode-v0.0.2-pre→ pre-release,vscode-v0.0.3→ rejected,vscode-v0.0.2-beta→ rejected rather than silently treated as stable.vsceandovsxboth accept--pre-release(checked--helpfor each rather than assuming).Documented in
RELEASING.mdandvscode-extension/AGENTS.md.Also carries your icon
"icon": "images/icon.png"at 128×128 registers asMicrosoft.VisualStudio.Services.Icons.Defaultin the VSIX, with the SVG source excluded via.vscodeignore. Confirmed in a rebuilt package — the VSIX I'd built earlier predated it, so it's worth knowing a rebuild was needed.🤖 Generated with Claude Code