Repository navigation
docs: re-verify cross-repo dependency status, and record a broken main - #40
Merged
Merged
Conversation
A dependency / actions / plugin sweep across all four Java repos on 2026-09-09,
re-measured rather than re-asserted. Five things in this file no longer matched
reality, and one thing was missing entirely.
The missing one first, because it is the only item that is not a freshness
question: srcmorph's main does not build. It pins net.ladenthin:llama 5.2.0,
which was never published -- Central's newest is 5.1.0 and llama-5.2.0.pom is a
404 -- and srcmorph declares no repository besides Central. It resolves only
where an earlier `mvn install` of java-llama.cpp left 5.2.0 in ~/.m2, which is
why local verification kept passing. Every srcmorph PR run since 2026-09-01 is
red at the first Maven step; the matching main runs were all cancelled by the
start gate, so no red main was ever visible. This file previously opened with
"All four repos are on the newest stable version of every dependency", which a
reader would reasonably take as "and they build" -- the warning block now says
otherwise, next to the sentence that misled.
The four stale claims:
* langchain4j 1.19.0 was recorded as "the only dependency genuinely behind a
stable upstream". It is on 1.20.0, which is Central's release. Closed.
* kotlin was pinned at 2.4.10 with the rationale "newer is an RC only". True
when written; Central now carries the plain 2.4.20 after -Beta1/2 and
-RC/-RC2/-RC3, so the pin expired rather than being overruled. Adopted, and
the registry row is retired in place rather than deleted so the reasoning
stays findable. It also now says what did NOT move with it:
android-llmservice's Compose compiler plugin, a different pin against AGP's
own built-in Kotlin.
* the jqwik row listed "BAF, jllama, srcmorph" while the standing-policy line
two paragraphs below already said "all 4". streambuffer does carry it. The
row was the wrong half of a contradiction the file was already carrying.
* advanced-security/maven-dependency-submission-action was recorded at @v5 in
all four; streambuffer is on @v6.
And one correction that matters more than a version number, because it would
have sent the next maintainer down a wrong path: the Dependabot note claimed the
github-actions ecosystem "rewrites the reference to the exact release tag" and
that a floating @vn alias cannot survive. Dependabot's own commit in streambuffer
(18080d3) is exactly -@v5 / +@v6. The premise about the missing
versioning-strategy knob is right; the conclusion drawn from it is not, and the
note now says so rather than being quietly deleted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
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
2 participants
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.
A dependency / actions / plugin sweep across all four Java repos on 2026-09-09, re-measured rather than re-asserted. Five things in
crossrepostatus.mdno longer matched reality, one thing was missing entirely, and one documented claim turned out to be falsified by a concrete case.The missing one, because it is not a freshness question
srcmorph's
maindoes not build, and no freshness sweep would have found it. It pinsnet.ladenthin:llama5.2.0, which was never published — Central's newest is5.1.0,llama-5.2.0.pomis a 404, and srcmorph declares no repository besides Central. It resolves only where an earliermvn installof java-llama.cpp left 5.2.0 in~/.m2, which is why local verification kept passing in good faith. Every srcmorph PR run since 2026-09-01 is red at the first Maven step; the matchingmainruns were allcancelledby the start gate, so no redmainwas ever visible.This file previously opened with "All four repos are on the newest stable version of every dependency" — which a reader would reasonably take to include "and they build". The warning block now sits directly next to that sentence. Tracked in srcmorph's own
TODO.md(bernardladenthin/srcmorph#207).Four stale claims
1.19.0, "the only dependency genuinely behind a stable upstream"1.20.0, which is Central's release — closed2.4.10, "newer is an RC only"2.4.20after-Beta1/2+-RC/-RC2/-RC3— the pin expired rather than being overruled, and was adoptedmaven-dependency-submission-action@v5in all four@v6The kotlin row is retired in place rather than deleted, so the reasoning stays findable, and it now also records what did not move with it:
android-llmservice's Compose compiler plugin, a different pin against AGP's own built-in Kotlin.One correction that would have misled the next maintainer
The Dependabot note claimed the
github-actionsecosystem "rewrites the reference to the exact release tag it's bumping to, and there is no way to configure it to preserve the floating alias", and drew a planning conclusion from it (standardize on exact pins, or re-float by hand forever).Dependabot's own commit in streambuffer (
18080d3) is exactly-@v5/+@v6. The floating major was preserved. The premise about the missingversioning-strategyknob is correct; the conclusion is not. The note now says so explicitly instead of being quietly deleted, because a silent removal would leave the next reader with no way to tell whether the claim was wrong or merely dropped.Verified unchanged
The checksum drift check was run verbatim as this file documents it: 10 of 10 byte-identical file groups match, including copy counts. No drift.
🤖 Generated with Claude Code
https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
Generated by Claude Code