Repository navigation
release: v2.1.0 - #301
Merged
Merged
release: v2.1.0#301
Conversation
Seven commits have been on main since 2f9276b (v2.0.0) with no release cut, so everything they added sat under [Unreleased] while VERSION still read 2.0.0. MINOR, not MAJOR. Every removal in this release was verified to have no caller or reader before it was made, and the two exports dropped from runtime_verification's __all__ -- ORCHESTRATOR_CONTRACT and verify_orchestrator_result -- had no consumer outside their own tests. That is not the v2.0.0 situation, whose own entry justifies MAJOR by "every existing v1.x installation is affected and none upgrades silently". The Step 1 behaviour change is real and user-visible, but it replaces a path that was already fail-silent rather than introducing a new incompatibility. Not PATCH either: FORCE_GRAPH_REBUILD and the orchestration-prompt verification are new behaviour, and features do not belong in a patch release. scripts/tools/sync-version.py did the propagation -- VERSION, README.md, CLAUDE.md, SRS.md and langgraph_engine/__init__.py all read 2.1.0, and `git diff --numstat` shows 1/1 and 3/3 rather than whole-file line-ending flips, which is the defect that script's own test suite exists to guard. release.py was NOT used for the changelog step. Its update_changelog() inserts before the first "## " heading, which is [Unreleased], so it would have produced a 2.1.0 entry whose only content was "Bumped from 2.0.0 to 2.1.0" while leaving every real change stranded below it under [Unreleased] -- a changelog asserting that the release contains nothing and that the work is still unreleased. The section was promoted by hand instead, and a fresh empty [Unreleased] left in place for the next cycle. Tags are handled separately after this merges, because they must point at the commit that lands on main rather than at this branch. Verified: 57 version and documentation tests including test_sync_version.py, all six CI gates, and the [2.1.0] heading matches the ISO-dated form rules/11-documentation-files.md requires. 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.
Seven commits have been on
mainsince2f9276b(v2.0.0) with no release cut, so everything they added sat under[Unreleased]whileVERSIONstill read2.0.0.Why MINOR
Every removal in this release was verified to have no caller or reader before it was made, and the two exports dropped from
runtime_verification.__all__—ORCHESTRATOR_CONTRACTandverify_orchestrator_result— had no consumer outside their own tests.That is not the v2.0.0 situation, whose own entry justifies MAJOR with "every existing v1.x installation is affected and none upgrades silently." The Step 1 behaviour change is real and user-visible, but it replaces a path that was already fail-silent rather than introducing a new incompatibility.
Not PATCH either:
FORCE_GRAPH_REBUILDand the orchestration-prompt verification are new behaviour, and features do not belong in a patch release.release.pywas deliberately not used for the changelogIts
update_changelog()inserts before the first##heading — which is## [Unreleased]. Running it would have produced:A changelog asserting the release contains nothing and that the work is still unreleased. The section was promoted by hand instead, with a fresh empty
[Unreleased]left for the next cycle.sync-version.pywas used, for the part it does correctly:VERSION,README.md,CLAUDE.md,SRS.mdandlanggraph_engine/__init__.pyall read2.1.0.git diff --numstatshows1/1and3/3rather than whole-file line-ending flips — the exact defect that script's own test suite exists to guard.Verified
57 version and documentation tests including
test_sync_version.py, all six CI gates, pre-commit clean (ruff / black / isort), and the[2.1.0]heading matches the ISO-dated formrules/11-documentation-files.mdrequires.Tags follow separately
Tags must point at the commit that lands on
main, not at this branch, so they are applied after merge:v2.0.0at2f9276b— that release was never taggedv2.1.0at the merge commitclaude-insightlineage (v2.5.1,v2.5.2,v2.7.0,v2.15.0,v2.16.0,v4.7.1,v4.8.2,v4.8.3,v4.8.4). They run tov4.8.4whileVERSIONreads2.1.0, which is why the tag list currently reads as though the project went backwards. Their SHAs are recorded before deletion — this is removing published history, so it is reversible by intent rather than by accident.🤖 Generated with Claude Code