Release v0.93.0, published by its own new automation - #44
Merged
Conversation
Everything merged since v0.92.3 sat on main untagged, which means it reached nobody: the update path compares the newest release tag with the installed VERSION, so five merged commits were invisible to every machine. Both hosts were still running 0.92.1 while the doctor reported them "at the latest released version". Contents: the 2026-07-28 MCP protocol revision on both bundled servers, the three defects reported from a Windows host (unignored credential backup, bootstrap alignment reported as mere existence, a documented command that does not exist), the compose image tag pinned to the package version, and the engine-update command renamed to `nexgen-update`. Minor, not patch: a renamed command and a protocol change are `### Changed`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GhAWHT7uwbvrvJg2Swibpt
Two halves of the same problem: work reached main and stopped there. Releasing was a manual step after the merge, and the step nobody's tooling depends on is the step that gets skipped. On 2026-07-30 main sat five merged commits past the newest tag, which meant they reached no machine at all - the update path compares the newest TAG with the installed VERSION, so unreleased work is invisible even to the doctor, which reported both hosts "at the latest released version". A workflow now tags and publishes whenever VERSION changes on main. Bumping VERSION is the whole act of releasing; everything after it is mechanical. Deliberately not a gate: it never fails a pull request and never blocks a merge. A VERSION touch that does not introduce a new version exits quietly, and a missing changelog section warns and still publishes rather than blocking. The other half is that the notice nobody acted on ended with "update is always deliberate", which reads as "no rush" - and both machines sat two releases behind while the doctor said so every single day. It now leads with what it is and carries the command to run. Still a warn, never a fail: being one release behind is not a broken machine. The tests that pinned the old sentence now pin the contract instead - the notice names the command, in both the bash and PowerShell twins, and stays a warn. Mutation-checked: dropping the command from either twin, or promoting the notice to a failure, turns them red. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GhAWHT7uwbvrvJg2Swibpt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GhAWHT7uwbvrvJg2Swibpt
matteopasseri407
changed the title
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
1 participant
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.
Everything merged since v0.92.3 sat on
mainuntagged, which means it reached nobody: the update path compares the newest release tag with the installedVERSION, so five merged commits were invisible to every machine. Both hosts were still on 0.92.1 whileagent-doctorreported the engine "at the latest released version" — the check sees release drift, not main drift.So this release also fixes the reason it was late, and is the first release published by that fix.
Contents
VERSIONchanges onmain. BumpingVERSIONis now the whole act of releasing. Deliberately not a gate: it never fails a PR, aVERSIONtouch introducing no new version exits quietly, and a missing changelog section warns and still publishes.NeXgen Engine update available: v0.93.0 (this machine runs v0.92.1) -- run: nexgen-update. Still a warn, never a failure: one release behind is not a broken machine. Both twins changed.2026-07-28MCP protocol revision on both bundled servers, backward compatible with every earlier revision (Serve MCP 2026-07-28 from both bundled servers #40).vault-mcpcompose image tag pinned to the package version (Serve MCP 2026-07-28 from both bundled servers #40).nexgen-update, previous name kept as a stub (Name the engine-update command after the engine #43).Minor rather than patch: a renamed command and a protocol change are
### Changed.Verification
736 passed, ruff baseline clean, both doctor twins syntax-checked,
release.ymlparsed. The release-notes extraction was run against the realCHANGELOG.mdfor this and two prior versions. The tests that pinned the old notice wording now pin the contract instead — the notice names the command, in both twins, and stays a warn; mutation-checked by dropping the command from either twin and by promoting the notice to a failure.Note on the earlier red run:
engine-tests-windowsfailed once ontest_antigravity_http_bridge_keeps_the_token_out_of_child_arguments, a 20s cap aroundnpx mcp-remoteon a cold runner. Passed on re-run and on four other runs tonight — a flaky timeout, unrelated to this diff, worth tightening separately.🤖 Generated with Claude Code
https://claude.ai/code/session_01GhAWHT7uwbvrvJg2Swibpt