Skip to content

release: 0.2.0 — give the version number something to point at - #11

Merged
bhyi4 merged 1 commit into
mainfrom
release/v0.2.0
Aug 28, 2026
Merged

release: 0.2.0 — give the version number something to point at#11
bhyi4 merged 1 commit into
mainfrom
release/v0.2.0

Conversation

@bhyi4

@bhyi4 bhyi4 commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

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 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 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.

The same defect had a packaging door

The version lives in two files:

file what it is
mcp/pyproject.toml what pip records, what a release is cut from
mcp/yeoul_mcp/__init__.py 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:

FAIL pyproject.toml and __init__.py carry the same version
  -- pyproject says '9.9.9', package says '0.2.0' -- a release cut now would ship two different numbers

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.

SERVERINFO TESTS FAILED: 8 checks accounted for, 7 expected -- one vanished without declaring itself

Suites (from the repo root)

serverInfo contract 8/8
_run contract 8/8
gates 72/72
pre-publish guard 43 files, clean

After merge

Tag v0.2.0 on the merge commit and cut the GitHub release from this CHANGELOG entry.

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>
@bhyi4
bhyi4 merged commit 317731b into main Aug 28, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant