[
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)
