The adapter tag format, corrected and pinned: no v - #194
Conversation
Caught while pre-flighting the tags for the 1.1.0 adapter release, by running publish.yml's own `case` statement rather than reading it. `publish.yml` strips a leading `v` from a KERNEL tag and reads an ADAPTER tag as everything after the last hyphen. So the two formats are different and the difference is fatal one way: adapters-langgraph-v1.1.0 tag=v1.1.0 version=1.1.0 REFUSED adapters-langgraph-1.1.0 tag=1.1.0 version=1.1.0 ACCEPTED adapters-langgraph-1.1 tag=1.1 version=1.1.0 ACCEPTED v0.10.0 tag=0.10.0 version=0.10.0 ACCEPTED The assertion message added with `adapters/PUBLISHED.toml` told a reader to push `adapters-<name>-v<version>`, which is the refused form. It is the message somebody reads at exactly the moment they are about to tag, so it is now the accepted form. `test_the_tag_an_adapter_release_needs_is_one_publish_yml_accepts` transcribes the workflow's two rules and runs them against the version in the tree, asserting both that the release's tag is accepted and that the `v` form is still refused. If publish.yml ever accepts the `v` form, that assertion fails and the guidance here changes with it, rather than silently becoming wrong in the other direction. `MAJOR.MINOR` is accepted as well as the full version, which is SPEC-v0.5 §6.2: adapters version by version line and the distribution carries the patch. Signed-off-by: arpan <contact@arpanghoshal.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe pull request documents adapter release tag rules and adds packaging coverage for the formats accepted by ChangesAdapter tag validation
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The release-tag guidance and regression coverage align with the publish workflow, with no actionable merge risk identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Caught while pre-flighting the tags for the 1.1.0 adapter release, by running
publish.yml's owncasestatement rather than reading it.The trap
publish.ymlstrips a leadingvfrom a kernel tag, and reads an adapter tag as everythingafter the last hyphen. The two formats differ, and the difference is fatal in one direction:
The
vthat is required on a kernel tag is fatal on an adapter tag, and the failure happensafter the tag is pushed.
What was wrong
The assertion message that shipped with
adapters/PUBLISHED.tomltold a reader to pushadapters-<name>-v<version>, which is the refused form. That message is read at exactly the momentsomebody is about to tag, so it is the worst place for it to be wrong. Corrected.
What stops it coming back
test_the_tag_an_adapter_release_needs_is_one_publish_yml_acceptstranscribes the workflow's tworules and runs them against the version in the tree. It asserts both directions:
vform is still refused — so ifpublish.ymlever starts accepting it, that assertionfails and the guidance in the test and in
PUBLISHED.tomlchanges in the same commit, rather thanbecoming quietly wrong the other way.
MAJOR.MINORis accepted as well as the full version, which isSPEC-v0.5 §6.2: adapters version byversion line and the distribution carries the patch.
Pre-flight, for when the tags go out
Run against PyPI just now, since a version number can never be reused:
All three match their
pyproject.tomlversions, so the workflow's version gate passes forv0.10.0,adapters-langgraph-1.1.0andadapters-openai-agents-1.1.0.Full gate:
all checks passed.Not merging and not tagging.
Summary by CodeRabbit
Documentation
Tests