Treat -pre version suffix as prerelease.

[dbrant]

What are you trying to accomplish?

Certain projects release packages with pre-release versions that have a suffix of -preN, which doesn't seem to get caught by dependabot as a prerelease, and gets submitted in a pull request as a stable package.

example prerelease:
https://github.com/maplibre/maplibre-native/releases/tag/android-v11.0.2-pre0

example erroneous pull request:
wikimedia/apps-android-wikipedia#4806

[abdulapopoola]

Thanks a lot @dbrant , could you please add a test and we can get this over the line :)

[dbrant]

Thanks a lot @dbrant , could you please add a test and we can get this over the line :)

whoops, of course -- how about now?

[abdulapopoola]

Merged and deployed! Thanks @dbrant !!

[deivid-rodriguez]

For what it's worth, we discussed this in the past at #6747 and decided not to deviate from what maven documents at https://maven.apache.org/pom.html#Version_Order_Specification. And -pre is not mentioned at all in there.

Funny enough, when we rejected adding "-preview", I actually mentioned "-pre" explicitly:

That said, I also feel package authors should stick to what their package manager supports, and not use their own versioning. Because now if another package author decides to name their prerelease versions as "pre", then we'll need to support that and when that stops?

[deivid-rodriguez]

Well, it was not really a clear decision, I totally understand taking the pragmatic approach over the correct, consistent one. Just saying that if we decide to do this, we may also want to reopen #6747.

[jonjanego]

Hi @dbrant - I wanted to give you heads up that we have decided to revisit this decision. See #10626

[dbrant]

@jonjanego Thanks for the note, and no worries -- it looks like we'll need to convince the MapLibre developers to adopt more standard prerelease versions instead.

[sultan]

The Dependabot team has decided to align strictly with Maven qualifiers:

• Changes to how Dependabot handles Maven versions #10626

This alignment makes sense for consistency across tools. Yet recurring issues show that Maven’s current handling of qualifiers is incomplete, impacting multiple companies and users:

• [MNG-7559] ComparableVersion vs versions with custom qualifiers apache/maven#8891
• fix: mark version with "preview" extension as pre-release (#6151) #6747
• Treat -pre version suffix as prerelease. #10207

These issues need to be addressed upstream in Maven Resolver. I am working to encourage Maven to adopt a fix through this PR:

• [MNG-7559] Fix version comparison with case insensitive lexical order apache/maven-resolver#1683

The voice of users and teams such as Dependabot can strongly influence Maven’s willingness to integrate this into Maven 4.

Proposed ordering:

• alpha < beta < milestone < pr = pre = preview < rc = cr < dev < snapshot < final = ga = release < sp

I edited the documentation to discourage the use of certain qualifiers:

• The use of pr, pre, preview is discouraged
• The use of cr is discouraged (use rc instead)
• The use of dev is discouraged
• The use of final, ga, release is discouraged (use no qualifier instead)
• The use of sp is discouraged (increment patch version instead)

As long as discouraged qualifiers continue to be used in practice, tools will still need to support them. Once they are phased out, however, support can be safely dropped.

Optional inclusions:

• ea (early access), edr, pfd (drafts), mr

Target PR to support:

• [MNG-7559] Fix version comparison with case insensitive lexical order apache/maven-resolver#1683

Supporting this upstream effort helps turn recurring patches into a durable solution for the ecosystem. You can help by adding your voice on the Maven Resolver PR — for example, by sharing which qualifiers affect your projects, or by confirming that consistent ordering would reduce the need for local workarounds. Demonstrating real impact from tools like Dependabot makes it harder for Maven to ignore these changes.

Thanks for your input.