release: 0.2.0 — give the version number something to point at - #11
Merged
Conversation
Until now no version number identified a build. `CHANGELOG.md` has said `[0.1.0] — unreleased` since the first commit on 2026-07-21 while eighteen more went in; there are no tags and no releases. That was nobody's decision — the number simply carried no weight, so nothing exposed its absence. #9 gave it weight. Once the server announces its own version in `serverInfo`, that string is what a client reads to tell builds apart — and it stayed `0.1.0` across the fix, so the server that reported the SDK's version and the server that reports its own are indistinguishable by the very field the fix repaired. Bumping is the other half of #9, not bookkeeping. 0.2.0, not 0.1.1: #10 changed behaviour for anyone using both tools — `arc-prereg` now refuses an arc whose spec is blank, and every close writes a `Second key` line into its `_SUMMARY`. Also closes the packaging door on the same defect. The version lives in two files: `pyproject.toml` is what pip records and what a release is cut from, `yeoul_mcp/__init__.py` is what the server speaks. Every existing check compared the server against `__init__.py`, so the two could drift with the suite still green — measured: setting pyproject alone to 9.9.9 kept it at 6/6. A check now fails when they disagree, verified by forcing the drift. That belongs in the suite rather than in a release checklist nobody runs, because cutting a release is exactly when the two get touched. The denominator guard added in #9 earned its place immediately: this commit added two checks and bumped the expected count by one, and the run refused itself with "8 checks accounted for, 7 expected" rather than reporting a green 8/8. Suites from the repo root: serverInfo 8/8 · _run contract 8/8 · gates 72/72 · pre-publish 43 files clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Until now no version number identified a build.
CHANGELOG.mdhas said[0.1.0] — unreleasedsince the first commit on 2026-07-21 while eighteen more went in; there are 0 tags and 0 releases.That was nobody's decision. The number carried no weight, so nothing exposed its absence.
Why it matters now
#9 gave it weight. Once the server announces its own version in
serverInfo, that string is what a client reads to tell builds apart — and it stayed0.1.0across the fix. So the server that reported the SDK's version and the server that reports its own are indistinguishable by the very field the fix repaired. Bumping is the other half of #9, not bookkeeping.0.2.0, not0.1.1: #10 changed behaviour for anyone using both tools —arc-preregnow refuses an arc whose spec is blank, and every close writes aSecond keyline into its_SUMMARY.The same defect had a packaging door
The version lives in two files:
mcp/pyproject.tomlmcp/yeoul_mcp/__init__.pyEvery existing check compared the server against
__init__.py, so the two could drift with the suite still green — measured: setting pyproject alone to9.9.9kept it at 6/6. A check now fails when they disagree, verified by forcing the drift:That belongs in the suite rather than in a release checklist nobody runs, because cutting a release is exactly when the two get touched.
The denominator guard earned its place immediately
The guard added in #9 caught this commit: two checks were added and the expected count was bumped by one, and the run refused itself rather than reporting a green 8/8.
Suites (from the repo root)
_runcontractAfter merge
Tag
v0.2.0on the merge commit and cut the GitHub release from this CHANGELOG entry.