Re: Question about handling “version qualifiers that carry meaning” in Maven
> it seems impossible to know It is as you say, everyone does their own thing. > how tools like Dependabot and friends should interpret "versions qualifiers that carry meaning They cannot, no better than we can. One has to engage with each individual project to understand what they are trying to convey in their versioning. When a project publishes an artifact with a version suffix like '-alpha' or '-beta', is it safe to use? I don't know, it depends on the project, and what that term means to them. Even first-party Maven plugins were putting out some '-M1', '-M2' suffixes for a while. What's that mean? Apparently 'Milestone X'. Is it safe to use? Apparently yes, but you'd have to read the release notes to know that, and it will not apply to other projects. I don't think Dependabot is particularly useful in general. It generates a lot of churn with keeping libraries updated, but it can't know if you *should* update. You could defer all of that until you're just about ready to make a release, do it all at once, and not care that some dependency had 10 minor updates between your releases. You don't gain anything by being on the bleeding edge with every dependency all the time. New versions are just as likely to have new bugs and CVEs, and if your slightly stale dependency has a CVE, consumers of your project are free to override your transitive dependencies themselves.
Question about handling “version qualifiers that carry meaning” in Maven
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!
