Record the adapters as 1.3.0, which is what PyPI has served since 09-15 - #224
Conversation
`adapters/PUBLISHED.toml` said 1.2.0 / `<0.12`. Both adapters were tagged and uploaded
at 1.3.0 / `<0.13` on 2026-09-15 and nobody came back to the record, which is the fourth
release running that this file has gone stale, in the file that documents the other
three.
**A stale record does not merely misinform: it switches the guard off.**
`test_a_widened_kernel_range_is_not_shipped_without_a_new_version` returns early when
the tree and the record disagree *and* the tree's version is higher, because that is
indistinguishable from a correct pending release. Probed both ways on this branch, with
the tree widened to `<0.14` and no version bump, which is the exact defect the test
exists to catch:
record 1.2.0 (stale) 2 passed <- the widening ships unnoticed
record 1.3.0 (fixed) 1 failed <- assert '1.3.0' != '1.3.0'
So this is not bookkeeping. It is the check coming back on.
`RECORDED` gains the 1.3.0 row so that range is frozen as the historical fact it is.
The header now carries the fourth recurrence and says what would actually end it:
`publish.yml` refusing to upload an adapter whose version and range this file does not
already record, which makes the record a precondition of the upload rather than a chore
after it. Not built here. It reverses the rule the file currently states and belongs in
its own change.
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 10 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe adapter publication records now show version 1.3.0 and kernel range ChangesAdapter publication records
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other Merge Risk: ⚪ Minimal · up to The adapter publication metadata now matches the versions and kernel ranges served on PyPI, with no unresolved merge-blocking risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Independent of #223 and #48; it blocks neither, and neither blocks it.
adapters/PUBLISHED.tomlrecords whatpip downloadactually gets. It said 1.2.0 /<0.12. Both adapters were tagged and uploaded at 1.3.0 /<0.13on 2026-09-15:That is the fourth release running this file has gone stale, in the file whose header documents the other three.
It was not bookkeeping, the guard was off
test_a_widened_kernel_range_is_not_shipped_without_a_new_versionreturns early when the tree and the record disagree and the tree carries the higher version, because that is exactly the shape of a correct pending release. A stale record therefore looks like a pending release forever, and the check stops checking.Probed both ways on this branch, with
adapters/langgraphwidened to<0.14and its version deliberately left alone, which is the precise defect the test exists to catch:assert 1.3.0 != 1.3.0RECORDEDgains the 1.3.0 row so that range is frozen as the historical fact it is.What would end this, and why it is not here
The header now carries the fourth recurrence and names the fix:
publish.ymlrefusing to upload an adapter whose version and kernel range this file does not already record. That makes the record a precondition of the upload rather than a chore after it, and the upload being the last thing that happens is precisely why the chore keeps being skipped.I did not build it. It reverses the rule the file currently states in its own header, and it touches the release path, so it is a decision rather than a cleanup. Say the word and it is a small change.
Summary by CodeRabbit
Documentation
Tests