fix(deps-maven): use <release> field as authoritative latest stable version#93
Merged
fix(deps-maven): use <release> field as authoritative latest stable version#93
Conversation
5bdd76d to
2a41902
Compare
…ersion Packages with legacy non-semver versions (e.g. guava r03-r09) were incorrectly reported as latest because compare_versions falls back to lexicographic comparison for non-numeric segments, placing "r09" above "33.5.0-jre". Parse the <release> element from maven-metadata.xml and return it directly as the latest stable version in get_latest_matching_typed. Fall back to sort-based selection only when <release> is absent. Adds get_metadata() private helper returning (versions, release) so the release field is available without changing the public API of get_versions_typed. Closes #91
eff6c1a to
8fcc018
Compare
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.
Summary
<release>element frommaven-metadata.xmland returns it directly as the latest stable version instead of sorting all versions<release>is absentget_metadata()helper returning(Vec<MavenVersion>, Option<String>)so bothget_versions_typedandget_latest_matching_typedshare a single fetch without changing the public APIRoot Cause
compare_versionsfalls back to lexicographic comparison for non-numeric segments, so legacy versions liker09(ASCII 114) sort higher than semver versions like33.5.0-jre(ASCII 51). The registry already provides the correct answer in<release>— it was simply ignored.Test Plan
test_parse_metadata_xml— updated to assertreleasefield is capturedtest_parse_metadata_xml_empty— updated to assertreleaseisNonewhen absenttest_parse_metadata_xml_legacy_versions_release_wins— new test verifying guava scenario:<release>33.5.0-jre</release>is returned even thoughr09sorts to the top of the version listcargo nextest run --workspace --all-features— 1315 tests passCloses #91