Renovate: Support Gradle versioning/sorting

[jcornaz]

What Renovate type are you using?
GitHub

Describe the bug

I received pull requests with this kind of message:

This PR contains the following updates:

| Package | Update | Change |
|---|---|---|
| org.jetbrains.kotlinx:kotlinx-coroutines-javafx | patch | 1.3.5 -> 1.3.5-native-mt-1.3.71-release-429 |

But documentation says:

By default, Renovate won't update any package versions to unstable versions (e.g. 4.0.0-rc3) unless the current version has the same major.minor.patch and was already unstable (e.g. it was already on 4.0.0-rc2). Renovate will also not "jump" unstable versions automatically, e.g. if you are on 4.0.0-rc2 and newer versions 4.0.0 and 4.1.0-alpha.1 exist then Renovate will update you to 4.0.0 only. If you need to force permanent unstable updates for a package, you can add a package rule setting ignoreUnstable to false.

As I was on the stable version 1.3.5, renovate should not propose me to update to the unstable version 1.3.5-native-mt-1.3.71-release-429.

Did you see anything helpful in debug logs?

No. But here's the job id: 156547292

To Reproduce

https://github.com/jcornaz/renovate-issue-reproducer/pull/2

EDIT: I am using gradle: https://docs.gradle.org/current/userguide/single_versions.html#version_ordering

[rarkins]

We should be using the Maven specification for determining stability and sort order, and fix if we’re non-compliant.

According to the Maven specification:

• is the new version considered unstable?
• which way do they sort?

[jcornaz]

Given: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN400

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

Applied to my example: 1.3.5-native-mt-1.3.71-release-429 is older than 1.3.5, and therefore should not be proposed as an update.

[viceice]

Looks like we have a bug here.

[rarkins]

Sounds like it, but this would be the best way to confirm for sure: https://octopus.com/blog/maven-versioning-explained

[rarkins]

BTW I have a doubt about whether that Oracle document is up to date, considering the results shown in that blog post I linked to:

You can see there are multiple cases that sort after the version without the qualifier, including 1.0-a and 1.0-whatever

[rarkins]

In fact the blog post claims:

Versions with unrecognised qualifiers are treated as later releases than an unqualified version, and unrecognised qualifiers are compared as case insensitive strings.

[jcornaz]

mmh... indeed. But that's quite problematic then. Because this behavior would be against semantic versioning.

Could at least maybe an option to let the user define the ordering of version numbers semantic-versioning vs maven?

[viceice]

So the update is correct. Maven has a very weird versioning scheme.

[jcornaz]

Yes, apparently, maven has a very weird versioning scheme, and order of version is not intuitive.

But still, this is not about version order. This is about renovate proposing to go from stable to unstable. Even if the version proposed is newer, renovate is not supposed to propose an unstable version.

I cannot find any clear documentation about what must be considered stable or not in maven context. But again, I think the semantic-version would be the least astonishing for everyone IMO.

[rarkins]

But still, this is not about version order. This is about renovate proposing to go from _stable_ to _unstable_.

I think you're incorrect here. The package is stable according to the Maven ecosystem it's been published into. 1.3.5-native-mt-1.3.71-release-429 is stable in Maven the same way 1.3.5-i-swear-on-my-life-this-is-stable is unstable in semver. Versioning schemes have specifications and we follow those by default or fix our code if they're not to spec.

Maven is not semantic versioning - it's independently defined. This seems like it's a mistake by the package author/publisher to not publish packages according to Maven's sort orders. Anyway, Renovate does allow you to override version schemes, e.g. I think the following override would work for you:

{
  "packageRules": [{
    "packageNames": ["org.jetbrains.kotlinx:kotlinx-coroutines-javafx"],
    "versioning": "semver"
  }]
}

Note though that you "lose" Maven versioning awareness forever when you do this. e.g. if they publish a non-semver-compliant version like 1.3.5.1 or 1.4.0-RELEASE then you won't get them.

[jcornaz]

Thanks @rarkins.

Indeed,

given the default seems compliant to maven versioning scheme, and that I have an option to configure renovate for using a semantic versioning scheme, I am fine.

Thanks for your help.

[jcornaz]

One more question, @rarkins is it possible to configure all my dependencies to consider semver by default?

[viceice]

use a packageRule

...
"packageRules": [
    {
      "managers": ["maven"],
      "versioning": "semver"
    }
]

[jcornaz]

Thanks @viceice.

However, sorry to reopen this, but according to the doc, renovate uses semver by default:

https://docs.renovatebot.com/configuration-options/#versioning

So something is wrong. Either the doc, or the implementation.

[viceice]

Yes, but managers can set a different default versioning. And maven is overriding it:

https://github.com/renovatebot/renovate/blob/7dd49f9b5df51c75afd9765468f0d01346ea5497/lib/manager/maven/index.ts#L11

[jcornaz]

Yes, but managers can set a different default versioning. And maven is overriding it:

So this is the doc which is wrong. I'm okay with that, but it shall be fixed.

[viceice]

I don't think the docs are wrong:

[jcornaz]

The fact that renovate "implements" some its own such as "docker" or "maven" does not imply that it is set by default.

However the default is explicitly documented to be "semver":

[jcornaz]

And event if I set the package rule:

"packageRules": [
    {
      "managers": ["maven"],
      "versioning": "semver"
    }
]

I still get this pull requests: https://github.com/jcornaz/renovate-issue-reproducer-2/pull/2

[viceice]

can you please past the relevant logs here?

[jcornaz]

Job ID is: 156834609

I'm not sure what part is relevant thought.

Should I past the full log here?

[viceice]

yes, because i can't see your job, if i'm not a maintainer of your project. Currently only @rarkins can see all job

[rarkins]

@viceice @jcornaz isn't this a gradle dependency? i.e. should be

"packageRules": [
    {
      "managers": ["gradle"],
      "versioning": "semver"
    }
]

or

"packageRules": [
    {
      "datasources": ["maven"],
      "versioning": "semver"
    }
]

However I don't recommend always using semver like the above

[viceice]

@rarkins You are right. @jcornaz Sorry, i havn't seen this.

[jcornaz]

Ok, thanks.

But since I am indeed using gradle, I'd expect to have gradle ordering by default:

https://docs.gradle.org/current/userguide/single_versions.html#version_ordering

A version with an extra non-numeric part is considered lower than a version without: 1.1.a < 1.1

To sum up there is two problems to solve:

1. Document the fact that the default depends on the manager and is not "semver"
2. Fix version ordering for gradle

[rarkins]

Good catch! I was not aware that Gradle had taken a different ordering path to Maven. We need to have versioning/gradle added @zharinov - can you take a look?

[renovate-release]

:tada: This issue has been resolved in version 19.188.0 :tada:

The release is available on:

• GitHub release
• 19.188.0

Your semantic-release bot :package::rocket: