fix: mark version with "preview" extension as pre-release (#6151)

[Thomas-Bergmann]

May the fix doesn't help for all variants, but it works as other versions extensions.
The version "12.1.0.jre11-preview" is now detected as pre-release.

[deivid-rodriguez]

The maven docs do mention "preview", so I think it makes sense to support it just like we support other qualifiers mentioned there. But it's unclear which one it is equivalent to, since it says:

Prefer 'alpha', 'beta' and 'milestone' qualifiers over 'ea' and 'preview'.

Also, does maven native software actually support this? Can you experiment a bit with maven-artifact to figure this out like in #6637 (comment) and below messages?

[Thomas-Bergmann]

The maven docs do mention "preview", so I think it makes sense to support it just like we support other qualifiers mentioned there. But it's unclear which one it is equivalent to, since it says:

Prefer 'alpha', 'beta' and 'milestone' qualifiers over 'ea' and 'preview'.

As you wrote "prefer over" implicitly allows "preview". So I assume, you just want to discuss the level of "preview". From my point of view the "preview" is comparable with a "release-candidate", comparable to "sneak-preview" for movies in cinemas. It's released to limited clients. For semver.org (semantic versioning spec) it's just a pre-release and as result there is no compatibility commitment for next releases.
Last point to clarify: Should dependabot prefer a "preview" release against "alpha", "beta", "milestone"?

• for the specific case (mssql-jdbc) driver there is no decision needed, they don't use "alpha" and so on. Are there other known cases?
• in general, I would tend to down-rate unofficial pre-release statements - but feels like a little bit wrong in that case

As long as there is no "official" declaration, it's a little bit personal feeling. If you have a good alternative, it's subject to change.

[deivid-rodriguez]

I think we should do the same as maven, since there's a chance that the docs are out of date and maven no longer supports this. That's why I pointed you to the comments in #6637, just to verify how maven actually sorts preview versions, so that we can do the same as maven.

[Thomas-Bergmann]

Sorry, I didn't understand your point. Maven is using "semver 1.0.0". quote:

• Maven does not consider any semantics implied by that specification.
• Important: This is only true for Semantic Versioning 1.0.0. The Maven version order algorithm is not compatible with Semantic Versioning 2.0.0
  In case "Dependabot" will follow that rules, and more precisely. Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive),

We would need to move "preview" behind (with higher rank) as GA.
With SemVer 2.0.0, all unknown extensions are "pre releases" and will have an lower priority as a GA.

From my point of view "maven" is one (for sure important) implementation of the semantic versioning specification, but not the specification. The order of versions in a repository is mostly unimportant. May that is the reason, why they don't support SemVer 2.0.0 (release in 2013).

since there's a chance that the docs are out of date and maven no longer supports this.

if that is the case (maven doesn't allow to publish such versions), there are no new "preview" releases available, and the implementation will still work correctly.

[deivid-rodriguez]

I guess this would be no big deal to introduce, since it's mentioned in the maven docs and we already seem to have another "special cases" not documented or supported by maven like dev. And it would be strange that a package would actually use "preview" in a "maven-compatible" way (and thus would miss updates if we introduce this).

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? Also, this naming is not even semver 2.0.0-compatible, since it has non-numeric characters before the prerelease marker (-), right?

If I type

    <dependency>
      <groupId>com.microsoft.sqlserver</groupId>
      <artifactId>mssql-jdbc</artifactId>
      <version>[12.1.0.jre11,12.2.0)</version>
    </dependency>

then maven resolves to 12.1.0.jre11-preview because it considers it's the highest version that matches the requirement.

I'm not convinced Dependabot should go against maven. Instead, I think mssql-jdbc should change their versioning policy to be compatible with maven.

That said, I don't have a very strong opinion so I'll let other maintainers chime in.

[Thomas-Bergmann]

I totally agree, it would be better that the Microsoft team adapts their pre-release identifier. I have seen many projects adapting their versioning, because now these can be updated automatically (thx to dependabot).
I had some research and found a PR at maven project around SemVer2 support -
Doesn't look straight forward.
I have more concerns about the "jre\d+" extension or the non existing "jre" extension in the future. Because these extensions are more intended to be a filter instead of an identifier of the "progress". But these information are very important to select a valid version. If there are no enhancements, dependabot will choose a version, which is not compatible with the currently used one. So there is also a leak in the specification for this kind of version markers.

[deivid-rodriguez]

It does seem complicated yeah! I subscribed to that ticket, but it does sounds like a complicated step to take for maven because of the shape of the existing world of maven package versions.

I'm still not sure about what's best here, and tempted to just move forward with your patch (thanks for proposing it regardless, by the way). I'll see if someone else chime in, and look back later.

[jeffwidman]

I'd prefer for us not to be opinionated on this beyond what Maven does...

So there is also a leak in the specification for this kind of version markers.

Unfortunately yes, but the maven implementation will do something. So we should just enforce whatever they do. IF you can demonstrate it behaves as in this PR, then we should merge, if there's an open ticket for maven to change behavior than we should hold off until/unless that lands.

Long term, we'd like to move toward leveraging maven itself instead of re-implementing maven behavior in ruby/regexes (but poorly). So the less customization we layer on top, the less painful/surprising that future migration will be for users.

[sultan]

Hi, owner of the mentioned PR here 👋

Maven is quite complicated in the Version Ordering because of companies that published deliverables before SemVer.

One of which companies being GitHub owners themselves...

With preview and sp1 names being on different ends of a normal release, it follows that a list of special names must be kept for either if not both ends...

This now causes versions software makers to choose either or not to make complicated algorithms and support such released versions names/qualifiers.

I'm fighting a war with Maven to have them implement SemVer correctly or add edge cases for infringing companies... until contenders stop using sp1 qualifiers and such.

I edited the Maven documentation and specification with them in the hope ppl would stop their bad habit. But it continues.

Maven themselves follow SemVer's logic backwards ... considering qualifiers names being after normal release. And maintaining a list of special names being before.

I will update this stalled PR for them to act on it.

Don't hesitate to comment afterwards.

Also do not wait for them to implement it correctly ... you can already make a better implementation algorithm to tackle the reality of the existing version names.

And I may gladly help with it when time comes.

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