feat(ci): version the VS Code extension with the rest of Apollon

[FelixTJDietrich]

Follows #808 (merged), which stopped a stray manifest edit from publishing. This PR makes the version itself meaningful.

Summary

vscode-extension/package.json has said 1.0.0 at every commit I can trace back to 2026-02-03. Nobody chose it; it is npm init's default. The Marketplace listing it supposedly describes is at 0.0.17, published 2024-11 — so that field has never driven a release. Meanwhile @tumaet/apollon, @tumaet/webapp and @tumaet/server are all at 5.1.0.

apollon-vscode joins them in a Changesets fixed group. It carries Apollon's version from now on.

What happens next

Nothing, until you merge a Version Packages PR. Then all four move together:

Package	Before	After
@tumaet/apollon	5.1.0	5.1.1
@tumaet/webapp	5.1.0	5.1.1
@tumaet/server	5.1.0	5.1.1
apollon-vscode	1.0.0	5.1.1

No version is hand-edited here, and that is deliberate. Changing vscode-extension/package.json's version in this PR would fire Release VS Code Extension on merge and publish immediately — the premature release #808 exists to prevent. Changesets aligns a fixed-group member to the group's highest version on its own, so 1.0.0 → 5.1.1 happens inside the Version Packages PR, and merging that is the deliberate release.

0.0.17 → 5.1.1 is monotonic, so the Marketplace accepts it. version-monotonicity.yml is satisfied for the same reason.

The trade, stated plainly

fixed means a changeset touching only the extension still bumps and republishes the library and the standalone images, at a new version, with identical content. That is the cost of one product number.

The alternative is linked, which bumps only what changed but lets the numbers drift apart again — which is the thing we're fixing. I've gone with fixed and written the trade into docs/contributor/deployment/npm-publishing.md so the next person doesn't rediscover it. Say the word and I'll switch to linked.

Two smaller consequences:

• Version Bump (VS Code extension) is deleted. It existed only to hand-bump a package Changesets was told to ignore. Extension work now records a pnpm changeset like everything else.
• apollon-vscode is no longer in ignore, which was also what kept it away from npm. Nothing publishes it there — release.yml runs Changesets in version-only mode — but I've written that constraint into the docs rather than leave it implicit. It ships to the Marketplace, never to npm.

CHANGELOG

vscode-extension/CHANGELOG.md is now what Changesets writes, matching library/CHANGELOG.md. Its prose preamble had to go: Changesets inserts each release directly after the first line, so anything under the heading gets shoved beneath every future release. I verified this — the first simulation produced exactly that mess.

The 0.0.17 migration note moved into the changeset. Review caught that it would have gone nowhere: release-vscode-extension.yml built its GitHub Release with --generate-notes and a static body, ignoring the changelog the library and standalone tracks both feed through extract-changelog.mjs. Fixed in 6d45a1c — the extension now uses the same path, so the note reaches the release body:

# apollon-vscode

## 5.1.1

### Patch Changes

- Apollon for VS Code now carries the same version as the rest of Apollon…
  If you have used the extension before, version `0.0.17` wrote
  "files.associations": { "*.apollon": "json" } into your user settings…

Verification

Every claim above was run, not reasoned. In a throwaway git worktree off this branch, with the real pnpm exec changeset version:

• All four packages land on 5.1.1; @tumaet/ui (not in the group) goes 0.0.1 → 0.0.2 as before; apollon-vscode-webview stays ignored and private.
• The generated vscode-extension/CHANGELOG.md has the shape shown above.
• node scripts/check-release-taxonomy.mjs — in sync.
• node scripts/sync-library-version.mjs --check — CDN refs match.
• pnpm exec changeset status — parses the new config, lists the five patches.
• actionlint .github/workflows/*.yml — 0 findings across every workflow (was 2 pre-existing before fix(ci): release the VS Code extension only when its version changes #808).
• prettier --check — clean.

One thing I could not run locally: changeset version with the real changelog-github generator, which resolves each changeset's commit on GitHub and fails on an unpushed one. I swapped in the default generator for the simulation; the GitHub generator only changes how release lines are worded, not which versions are computed. It runs for real in the Version Packages PR.

Steps for testing

1. Merge this.
2. release.yml opens (or updates) the Version Packages PR. Confirm it contains apollon-vscode: 1.0.0 → 5.1.1 alongside the other three.
3. Merging that PR is the release. It changes vscode-extension/package.json, so Release VS Code Extension fires, check sees the version changed, and the VSIX is built, attested and published to the Marketplace + Open VSX as 5.1.1.
4. Before that, worth one workflow_dispatch of Release VS Code Extension with dry_run: true to prove fix(ci): release the VS Code extension only when its version changes #808's .nvmrc fix on a real runner — it can only fail where there is no checkout.

Checklist

• Linked to a related issue (if applicable)
• Added a changeset whose summary is written in the user's voice (pnpm changeset, how) — or this PR doesn't touch a Changesets-tracked package (@tumaet/apollon, @tumaet/webapp, @tumaet/server)
• PR title's Conventional Commit type (feat/fix/…) matches the kind of change — it groups the release note
• Tests added or updated
• Ran pnpm lint && pnpm format:check && pnpm build && pnpm test locally — green
• Documentation updated (if applicable)
• Screenshots or screencasts attached (if a UI change)

_{No tests: this is release configuration. It was instead exercised end-to-end with the real changeset version in a throwaway worktree, as described above.}

[Claudia-Anthropica]

@FelixTJDietrich The fixed-group config itself behaves as described; I verified changeset status and a temp changeset version simulation produce 5.1.1 across the four packages. I’m requesting changes because the VS Code release job still does not publish the generated changelog text, and a contributor guide still tells people to skip VS Code changesets.

[Claudia-Anthropica]

@FelixTJDietrich All feedback addressed, nice work.

[FelixTJDietrich]

Rebased onto main (8e01555, 9ff0482). #808 was squash-merged as d16a68d, so this branch was still carrying the pre-squash commit — same content, different SHA, hence the conflict. Dropped it with git rebase --onto origin/main 8eae0bb4; no textual conflicts.

Re-verified after the rebase rather than assuming, since the merge base moved:

• fix(ci): release the VS Code extension only when its version changes #808's work is intact on the result (version guard, .nvmrc sparse checkout, fetch-depth: 2), and this branch's only change to release-vscode-extension.yml is the release-notes path.
• actionlint clean across all workflows; check-release-taxonomy, sync-library-version --check, prettier, changeset status all pass.
• The full pnpm changeset:version still lands @tumaet/apollon, @tumaet/webapp, @tumaet/server and apollon-vscode on 5.1.1.
• On that simulated version-bump commit the guard reads before=1.0.0 now=5.1.1 and correctly proceeds to publish, and extract-changelog.mjs renders the extension's release body.