`display-dependency-updates` version comparison algorithm bug for `-pfd`

[garretwilson]

I have the following managed dependency in my Maven POM:

<dependency>
  <groupId>javax.faces</groupId>
  <artifactId>javax.faces-api</artifactId>
  <version>2.3</version>
  <scope>provided</scope>
</dependency>

However when I invoke mvn versions:display-dependency-updates, Versions Maven Plugin shows me:

javax.faces:javax.faces-api ........................... 2.3 -> 2.3-pfd

Offhand I don't know what -pfd means (pre-final-deliverable?), but that's irrelevant. You can see on Maven Central that this version was released before v2.3.

The semantic versioning specification says that any -* suffix (which would include -pfd) is considered a "pre-release" version. Thus 2.3-pfd is considered a pre-release version of 2.3 and should not be listed as a new available version. (The specification then goes on to explain how to calculate version precedence for pre-release suffixes, but that's even not the case here, as any pre-release version should not appear greater than the release version.)

(On a related note, the specification also says that version metadata, that is suffixes beginning with +*, must be completely ignored when determining version precedence.)

[andrzejj0]

Confirmed

[garretwilson]

Thank you, @ajarmoniuk . It's really so nice to see this project is getting quick and useful responses. I sincerely appreciate it. Have a good weekend.

[andrzejj0]

No worries! Looking into it. Have a nice weekend too!

[andrzejj0]

Apparently, the problem also exists in Maven itself -- looks like the class ComparableVersion got carried over to org.apache.maven.artifact.versioning.ComparableVersion there.

If you use a range specification like

<dependency>
  <groupId>javax.faces</groupId>
  <artifactId>javax.faces-api</artifactId>
  <version>[2.3,)</version>
</dependency>

your project will actually depend on version 2.3-pfd (you can check with e.g. dependency:tree). But this is indeed incorrect.

[andrzejj0]

@slachiewicz

[andrzejj0]

https://issues.apache.org/jira/browse/MNG-7559

[mprins]

both javadoc and version policy proposal describe exactly this behaviour;

Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive),

I have failed to find any Maven documentation that says Maven follows what semver describes.

https://octopus.com/blog/maven-versioning-explained provides a very readable summary

[andrzejj0]

On the other hand, https://www.mojohaus.org/versions-maven-plugin/version-rules.html and e.g. https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401 seem to promote a more generic approach, conflicting with the one presented in the blog you mention, @mprins

The thing about this blog post is that it actually treats the class as a source of truth. But we kinda can read code anyway, can't we?

All versions with a qualifier are older than the same version without a qualifier (release version).

Unless we only consider "standard" qualifiers as qualifiers.

[mprins]

I don't think linking to an oracle document from 2015 is helpful at all; it is clear from the maven versioning wiki that I pointed to (and that the mojohaus document you gave us links to in the first line) that unknown qualifiers added to a version are considered to be a higher version than no qualifier (eg. commonly used Final, GA by hibernate work fine as do things like jre8, jre17, atlassian-1, atlassian-2, redhat-2... https://mvnrepository.com/artifact/jaxen/jaxen?repo=redhat-ga )

[andrzejj0]

I'm questioning the implementation, but the blog you're citing provides that implementation in question as the authority...

Any reason to disqualify the Oracle document based on its age? Has something changed in the meanwhile?

Anyway, I'll wait for someone else to chime in.

[hboutemy]

https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning is our Maven reference, written and implemented before Semver 1.0.0 even existed
Changing version comparison won't bring much value: whatever convention is written by someone, other people use other convention, then there are edge cases...

[andrzejj0]

Then this should be stated clearly in the documentation. I'll go ahead and add a link to this to the docs.

[garretwilson]

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 "other people user other convention" problem @hboutemy mentioned. 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.

[garretwilson]

Let me ask you this question: looking at Maven Central, does it appear that the authors of javax.faces:javax.faces-api intended the -pfd suffix to be interpreted as Maven interprets it? Or did they intend for it to be interpreted according to how Semantic Version interprets it? The answer is clear: they intended it to be interpreted as Semantic Versioning interprets it. They likely didn't even know this Maven versioning documentation existed.

Changing version comparison won't bring much value …

What is the value of furthering some noble but outdated versioning logic that the average developer doesn't even know about, when the average developer is instead publishing artifacts that follow Semantic Versioning?

Are there very many artifacts published using a non-well-known extension for which the developer intended the Maven rules to apply? In this case at least, they expected Semantic Version rules to apply.