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.