Repository navigation
Check the documented ModelJars version against Central, not just against itself - #354
Merged
Merged
Conversation
…nst itself
The documentation advertised ModelJars 0.1.75 while Central served 0.1.76. Earlier today it
advertised 0.1.65 against a published 0.1.75 -- ten releases, and 0.1.65 predates the ONNX intake
and the speech loader, so a reader following the docs got a runtime that could not load models the
catalog advertises. Fixing that value is what left it one release behind: 0.1.76 shipped an hour
after the correction.
verifyDocumentation was never going to catch either. It keeps all five pages that interpolate
{modeljars-version} consistent with the modeljarsVersion property, and the property is what is
wrong. Nothing resolves it -- no module depends on ModelJars and no lockfile pins it -- so no build
fails when it goes stale. I noted this gap when correcting 0.1.65 and deferred it; it recurred
within the hour, which answers whether it was worth deferring.
scripts/verify-modeljars-currency.py takes Maven Central as the authority, for the reason
ModelJars' own verify-site-version.mjs gives: a source tag does not prove a reader can resolve the
dependency the documentation shows. Unreachable Central exits non-zero rather than passing, since a
check that waves through on network failure is how this shape of check first shipped doing nothing.
It accepts an explicit released version so the mutation check does not depend on the network, which
is also how verify-site-version.mjs is driven. Registered in scripts/integrity/mutation-check.py
with the 0.1.65 defect as its mutation: all 9 guards pass clean and fail on their own defect.
verifyDocumentation, verifyReleaseMetadata and complianceCheck pass.
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.
The value, and the reason it keeps going stale
The docs advertised ModelJars 0.1.75 while Central serves 0.1.76. #350 had just corrected
them from 0.1.65 against a published 0.1.75 — ten releases, and 0.1.65 predates the ONNX intake
and the speech loader, so a reader following the docs got a runtime that could not load models the
catalog advertises. 0.1.76 then shipped an hour after that correction, so the fix left it one
release behind.
verifyDocumentationwas never going to catch either case. It keeps the five pages thatinterpolate
{modeljars-version}consistent with themodeljarsVersionproperty — and the propertyis the thing that is wrong. Nothing resolves it: no module depends on ModelJars, no lockfile pins
it, so no build fails when it drifts.
I flagged exactly this gap in #350 and deferred it as "a separate change". It recurred within the
hour. That settles whether it was worth deferring.
The guard
scripts/verify-modeljars-currency.pytakes Maven Central as the authority, for the reasonModelJars'
verify-site-version.mjsstates: a source tag does not prove a reader can resolve thedependency the documentation shows.
shape "first shipped doing nothing" in this repo's history, and that is the mechanism.
same argument
verify-site-version.mjstakes.scripts/integrity/mutation-check.pywith the 0.1.65 defect as its mutation,because this repo's own rule is that a guard which cannot detect the defect it was written for is
worse than no guard.
Gates
verifyDocumentation,verifyReleaseMetadata,complianceCheck— BUILD SUCCESSFUL.scripts/integrity/mutation-check.py— 9 of 9.