Skip to content

test: keep release version pins aligned across packaging files - #31

Merged
ashmoonori-afk merged 1 commit into
mainfrom
test/m3-6-version-alignment
Oct 8, 2026
Merged

ashmoonori-afk merged 1 commit into
mainfrom
test/m3-6-version-alignment

Conversation

@ashmoonori-afk

Copy link
Copy Markdown
Owner

Finding

Fixes M3-6 (P2) from the 2026-10-08 Opus-verified review. The release version 0.4.0 is hard-coded in pyproject.toml, birkin_mnemosyne/__init__.py (__version__, surfaced by mnemosyne-mcp --version and MCP serverInfo.version), integrations/hermes/pyproject.toml, integrations/hermes/plugin.yaml, integrations/hermes/README.md and integrations/openclaw/README.md. No test keeps them aligned, so a release bump can silently leave stale pins behind.

Change

Adds tests/test_version_alignment.py, which reads the version from the root pyproject.toml and asserts:

  • birkin_mnemosyne.__version__ equals it;
  • integrations/hermes/pyproject.toml and integrations/hermes/plugin.yaml pin "birkin-mnemosyne==<version>";
  • integrations/hermes/README.md and integrations/openclaw/README.md mention ==<version>.

Each assertion message names the file the maintainer has to bump. The test uses tomllib on Python 3.11+ and falls back to a regex scoped to the [project] table on 3.10, so it never imports tomllib unconditionally (requires-python = ">=3.10").

Policy check: #24 ("keep hermes plugin pins installable during quarantine") exempts birkin-mnemosyne from the uv exclude-newer cutoff because it is an exact, reviewed pin of our own release. Nothing there says the Hermes pin should lag the core version, so the test asserts equality: a release bump must update the Hermes pin in the same change. If the pin is ever meant to lag, this test is the place to encode that.

No source changes: all six locations currently agree on 0.4.0.

Tests

  • New: tests/test_version_alignment.py (3 tests).
  • Failing-before does not apply (versions currently agree). Instead, drift was demonstrated by temporarily changing one file at a time from 0.4.0 to 0.3.9 (not committed):
    • plugin.yaml -> AssertionError: integrations/hermes/plugin.yaml must pin 'birkin-mnemosyne==0.4.0'; bump its dependency
    • openclaw/README.md -> AssertionError: integrations/openclaw/README.md must reference '==0.4.0'; bump its install line
    • __init__.py -> AssertionError: birkin_mnemosyne/__init__.py __version__ is '0.3.9' but pyproject.toml says '0.4.0'; bump __version__
  • The 3.10 fallback branch was exercised on 3.14 by forcing sys.version_info = (3, 10, 14) with tomllib imports blocked; all three tests pass on that path. The CI 3.10 job will run it natively.
  • Full suite: 718 passed, 2 skipped (baseline 715 passed, 2 skipped, plus 3 new).

Risk

None user-visible; this adds a test only. Future release bumps must update all six locations together or CI fails with a message naming the stale file.

🤖 Generated with Claude Code

Read the release version from the root pyproject.toml (tomllib on 3.11+,
a [project]-scoped regex on 3.10) and assert that __version__, both Hermes
manifests and both integration READMEs reference the same release.

Refs M3-6.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ashmoonori-afk

Copy link
Copy Markdown
Owner Author

APPROVED at 2a851a2

Independent review completed.

  • Full suite on a clean worktree at the head sha (Python 3.14.4): 718 passed, 2 skipped in 44.01s. New file alone: 3 passed.
  • Drift detection proven in a scratch worktree (Hermes pyproject.toml set to 0.3.9; Hermes README set to 0.3.9; root pyproject.toml bumped alone to 0.4.1). Each case fails with an assertion naming the stale file. Reverting each edit makes the tests pass again.
  • Python 3.10 path: tomllib is only imported inside the sys.version_info >= (3, 11) branch. I ran the regex fallback with version_info forced to (3, 10, 14) and tomllib imports blocked; it returned 0.4.0 and all three tests passed. CI core (stdlib only, ubuntu-latest, py3.10) has passed. The other 3.10 jobs were still pending when I posted.
  • The fix: declare exact dependency pins and quarantine exemptions #24 quarantine policy holds. The test only asserts the exact pin "birkin-mnemosyne==<version>" and does not touch [tool.uv.exclude-newer-package]. An exact, reviewed pin of our own current release is what that exemption relies on.
  • Release flow: a bump must touch all six files in one PR. That is reasonable because they are all hand-edited one-liners. release.yml is workflow_dispatch and does not depend on this test, so publishing is never blocked. A partial bump PR is caught instead. Merge the bump and publish to PyPI close together, because the Hermes/OpenClaw pins on main point at the new version before it exists on PyPI.
  • The 0.4.0 strings found by grep -rn are exactly these six locations; the test does not miss any. There are no added lines with Hangul. The PR body is in English, cites M3-6 and makes no search-quality claims.

Non-blocking:

  • Each loop test stops at the first stale file. In a core-only bump it reports the Hermes pyproject.toml but not plugin.yaml, and the Hermes README but not the OpenClaw README. Collecting the stale files and asserting the list is empty would show the whole set at once.
  • The README check is a substring test, so ==0.4.1 would also match a stale ==0.4.10. Using re.search(rf"=={re.escape(v)}(?![\d.])", ...) would close that gap.
  • The 3.10 fallback regex only accepts version = "..." with double quotes and single spaces. That is fine for the current file. If it ever fails on reformatting, the error message is clear.

@ashmoonori-afk
ashmoonori-afk merged commit abc99d4 into main Oct 8, 2026
13 checks passed
@ashmoonori-afk
ashmoonori-afk deleted the test/m3-6-version-alignment branch October 8, 2026 03:57
@ashmoonori-afk ashmoonori-afk mentioned this pull request Oct 9, 2026
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