Hi all,
I’m seeking your thoughts on how tools like Dependabot and friends should interpret "versions qualifiers that carry meaning meaning" in the ecosystem. In Maven, many library authors encode compatibility constraints in the version string, making it hard to tell if two versions are compatible. While classifiers or other mechanisms would be preferable, this reflects the current state of the ecosystem and poses challenges for tools. Examples: Category: JRE or JDK suffix Example A: 13.2.1.jre8 Example B: 13.2.1.jdk8 Description: Users generally avoid upgrading from JRE to JDK due to potential compatibility issues. The assumption that JDK always works is not guaranteed. Category: Commercial vs open source Example A: 7.9.0.ccs Example B: 7.9.0.cs Description: Users must know which variant requires a license; features may differ. Category: Embedded git digest Example A: 5622.c9c3051619f5 Example B: 5623.79d2ddf61465 Description: Versions are often part of the same release, but git digests can complicate compatibility. Category: Arbitrary suffix Example A: 5622-my-suffix Example B: 5623-suffix Description: it seems impossible to know here Maven does not seen to enforce these conventions (and likely should not). I’m curious how tools like Dependabot should handle them, or whether Maven provides any APIs to assist. To clarify, my focus is not on sorting versions, but on determining whether they should be considered for sorting at all. For example, using the scenarios above, 7.9.1.ccs may be technically greater than 7.9.0.ce, but that does not imply compatibility or that they should be treated as equivalent for upgrade purposes. In other words, 7.9.1.ccs > 7.9.0.ce, but the differing variants mean compatibility cannot be assumed. Thank you!
