versions: `display-dependency-updates` version comparison algorithm bug for `-pfd`
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.)
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 42 (34 by maintainers)
Commits related to this issue
- #744 fix maven version comparison — committed to sultan/versions-maven-plugin by sultan 2 years ago
- #744 fix maven version comparison — committed to sultan/versions-maven-plugin by sultan 2 years ago
- #744 fix maven version comparison — committed to sultan/versions-maven-plugin by sultan 2 years ago
- #744 fix maven version comparison — committed to sultan/versions-maven-plugin by sultan 2 years ago
It does: https://github.com/apache/maven/blob/master/.github/pull_request_template.md
I also would expect every committer to check a PR for this before merging it.
Oh and re your question, any “non-standard”, so, e.g. “-pfd” qualifier is treated as later than the release by Maven, that’s the premise of this whole thread.
This is specific to Maven btw.
FYI I did some checking and found out what “-pfd” means in this case: apparently it is a stage in the Java Community Process that means “Proposed Final Draft” (e.g. Enterprise Java Beans 3.0 Proposed Final Draft). In other words, they are using it in much the same way as other teams use the term “release candidate”. This means all the Java Specification Requests will likely wind up with a
-pfdartifact in Maven (which will be sorted incorrectly) before each final release.Me too.
As
2.3has no qualifier, it’s considered as2.3-finalfor comparison, andpfdcomes after all special tokens.Time of the release does not participate in the process. Only version string.
https://maven.apache.org/pom.html#version-order-specification
Let me ask you this question: looking at Maven Central, does it appear that the authors of
javax.faces:javax.faces-apiintended the-pfdsuffix 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.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.
https://issues.apache.org/jira/browse/MNG-7559
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.