VS Code extension 1.0 — cut the release the code already justifies

[thomas-stegemann]

The extension has outgrown its version number. #589 (resolve the CLI from a workspace tool manifest), #590 (offer a managed download when none is installed) and #591 (workspace-local storage) closed the last construction sites, and none of that has reached anybody: the Marketplace still serves 0.1.2 from 2026-08-18, while main carries 0.2.0.

Cutting 1.0.0 is the honest description of that state — 0.2.0 would understate it, and shipping nothing understates it further.

Why 1.0 rather than another 0.x

1.0 is a promise about the surface, not about ambition. It says the settings keys and command ids stay put, and that a change to them is a major version. The extension is at the point where that promise is cheap to make and expensive to postpone: every additional 0.x release trains users to expect churn that is no longer happening.

Version numbering stays independent of Bowire's (#101). The extension drives an installed CLI rather than bundling one, and it hosts anything from its floor upwards — a shared number would assert a coupling that does not exist, and would force an extension release on every Bowire release.

Not blocking, after all

This section used to hold #613 and claim 1.0 could not ship without it. That was a sequencing opinion written as a constraint, and it does not survive contact with the facts: publishing works today through VSCE_PAT, and that path is good until 2026-12-01. While it works, a fix can be shipped the day it is needed — which is the only thing the "worst possible order" argument was actually protecting.

So the two are independent. #613 keeps its own deadline and must land well before December; 1.0 does not wait on it.

Before the cut

• Freeze the public surface. Walk the bowire.* settings keys and the command ids once and decide they are the names we keep. After 1.0 a rename is a breaking change; before it, it is a rename.
• Re-check the CLI version floor. The extension pins 2.0.0 and hosts anything newer. Bowire is at 2.5.0 and has grown --no-browser, project storage and the plugin-directory resolution since. If the extension now relies on any of it, the floor is a lie and users meet a runtime failure where a clear "your CLI is too old" was supposed to be.
• Marketplace listing. README, screenshot, categories and the description as they will be read by someone who has never heard of Bowire — the listing is the product page, and 1.0 is when people arrive at it.

Acceptance

• kuestenlogik.bowire-vscode 1.0.0 on the Marketplace
• Settings keys and command ids documented as stable, with the version floor stated next to them

VSCE_PAT removal and the Entra publish path moved to #613, where the deadline lives. Tying them to this cut made 1.0 wait on an Azure-side action it never needed.

Explicitly not in scope

• JetBrains plugin (Tugboat — JetBrains plugin (IntelliJ platform) #588) — its own timeline
• Bundling Bowire binaries in the extension (Tugboat — VS Code workbench extension #101 weighed and rejected this; ~120 MB per platform and an extension release per Bowire release)

[thomas-stegemann]

Worked through the "before the cut" list. Two of the three are done, and one of them turned up a real defect.

Version floor — was wrong, now fixed (67ad4c89).

The extension pinned 2.0.0 and passes --port-file, which only arrived in 2.5.0. Anything in 2.0.0–2.4.x therefore passed the version guard, got spawned, and died on an argument it had never heard of — surfacing as "exited before it started serving", which describes the symptom and names nothing actionable. The floor was set when buildArgs emitted three arguments and never moved when a fourth was added; the doc comment above it still listed only the original three, which is where the omission is visible in hindsight.

Raised to 2.5.0 rather than made conditional: --port-file deliberately replaced banner-scraping (a log line, so it vanishes at a quieter log level), so there is no lower path to fall back to. PINNED_CLI_VERSION in the managed download already said 2.5.0 — the floor was the one number that had not been carried along. A test now covers 2.0.0 / 2.3.7 / 2.4.1 explicitly, and a fixture that used a 2.4.0 CLI to stand for "a working one" was quietly depending on the old floor.

Worth noting for the release: this defect is not in the published 0.1.2, because --port-file postdates it. It would have shipped with the 1.0 cut.

Public surface — reviewed, no changes needed.

Two commands (bowire.openWorkbench, bowire.showCli) and two settings (bowire.cliPath, bowire.autoDownload). The settings carry enum + enumDescriptions, sensible scopes (machine-overridable / machine) and cross-referencing descriptions. Small, consistently named, nothing that reads like a placeholder. Freezing this surface at 1.0 costs nothing.

Marketplace listing — mostly there, two fixes (eecd5c7c).

Icon, categories, keywords, repository, homepage, licence, screenshot and a changelog are all present. Two things were not:

• CHANGELOG.md was sorted oldest-first, so the marketplace changelog tab opened on 0.1.1 and required scrolling past every release to reach what just shipped. Reversed.
• No bugs.url, which is what puts an issues link on the marketplace page. A reader wanting to report something landed on the repository root instead.

Remaining

• Move the VS Code Marketplace publish off PATs to Entra ID before 2026-12-01 #613 — the Azure side (managed identity, federated credential, publisher membership), then one real publish. Still the blocker; nothing in this pass touched it.
• Bump version to 1.0.0 and add the changelog entry — deliberately left until Move the VS Code Marketplace publish off PATs to Entra ID before 2026-12-01 #613 is proven, so the cut and the first Entra publish are the same act.

[thomas-stegemann]

Decoupled from #613. The dependency was asserted here, not real: publishing works through VSCE_PAT until 2026-12-01, so a fix can be shipped the day it is needed — which is the whole of what the sequencing argument was protecting. #613 keeps its deadline and runs on its own track.

All three "before the cut" items are already ticked, so what remains for 1.0 is the cut itself.