[ https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649055#comment-17649055 ]
Garret Wilson commented on MNG-7559: ------------------------------------ {quote} indeed not a bug, but the spec could be improved to take more milestones qualifiers like the PREVIEW qualifiers used on jdbc drivers {quote} With the decision to add even more "magic strings", is it any surprise this is turning into a "mess", as [~michael-o] called it? Perhaps the time has come for Maven to simply follow Semantic Versioning, as everyone expects anyway? As I [commented|https://github.com/mojohaus/versions/issues/744#issuecomment-1272343117] on the [original bug I filed|https://github.com/mojohaus/versions/issues/744]: {quote}It's not surprising that at one time Maven created some reasonable, internally consistent versioning schema, and it is notable and commendable that Maven actually created a specification for this at a time when so many projects were making versioning format decisions based upon arbitrary whims of the current developer. I would guess that Maven probably even had some influence on the codification of the Semantic Versioning specification. But it is unquestionable that the software industry is now converging around Semantic Version, and the last thing that we need is a central component of the build pipeline to be marching to some other tune. Just because something was specified at one time doesn't mean it can't be improved in a later version. HTML 4 wasn't bad. We should not be using HTML 4 in 2022—we should be using HTML 5, because that good specification has been improved. It is certainly illustrative that after I filed this bug, initially everyone _expected_ it to be a bug until we found some little-known Maven versioning specification. This expectation illustrates that in 2022 developers _expect_ to be using Semantic Versioning. Developer *do _not_ expect that certain suffixes are special-cased and treated differently based upon whether they are "well known" or not.* Marking certain limited set of identifiers as "well-known" leads exactly to [the never-ending dilemma of which special strings to support and how to deal with them]. It is better to treat them all the same. The difference in version number interpretation between Maven versions and Semantic Versions is small. It is time for Maven to be using Semantic Versioning, in the least regarding the comparison of pre-release version suffixes. {quote} > ComparableVersion vs versions with custom qualifiers > ---------------------------------------------------- > > Key: MNG-7559 > URL: https://issues.apache.org/jira/browse/MNG-7559 > Project: Maven > Issue Type: Bug > Affects Versions: 3.8.3 > Reporter: Andrzej Jarmoniuk > Assignee: Elliotte Rusty Harold > Priority: Major > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3 > > Attachments: image-2022-10-22-18-22-11-591.png > > > Since I know that ComparableVersion was brought to Maven from > versions-maven-plugin, it turns out the bug described here: > https://github.com/mojohaus/versions-maven-plugin/issues/744 > also exists in maven, at least in 3.8.3. > According to the maven version spec, versions containing a qualifier should > be treated as less major than the same versions without the qualifier. > Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*", > "-alpha", etc. > However, it looks like "2.3-pfd" is deemed less major than "2.3". > {code:java} > @Test > public void testComparableVersionWithCustomQualifier() > { > assertThat( new ComparableVersion( "2.3" ).compareTo( new > ComparableVersion( "2.3-pfd" ) ), > greaterThan( 0 ) ); > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)