Renovate created PR for pre-release upgrade

[Halil İbrahim Şener]

What Renovate type, platform and version are you using?

Self-hosted Renovate Open Source CLI (using the docker image renovate/renovate:23.77.0) on GitHub

Describe the bug

As the summary says, we have an upgrade PR for a pre-release version. You can see here PicnicSupermarket/oss-parent#81. Also, the log says minor for updateType. 🤷‍♂️

Relevant debug logs

{
  "datasource": "maven",
  "depName": "org.immutables:value-processor",
  "currentValue": "2.8.8",
  "fileReplacePosition": 4891,
  "registryUrls": ["https://repo.maven.apache.org/maven2"],
  "groupName": "version.immutables",
  "depIndex": 28,
  "updates": [
    {
      "fromVersion": "2.8.8",
      "toVersion": "2.8.9-ea-1",
      "newValue": "2.8.9-ea-1",
      "newMajor": 2,
      "newMinor": 8,
      "updateType": "minor",
      "isSingleVersion": true
    }
  ],
  "warnings": [],
  "fixedVersion": "2.8.8",
  "dependencyUrl": "org/immutables/value-processor"
},

To Reproduce

It should be producible by adding org.immutables:value-processor:2.8.8 dependency. I haven't tested, so maybe it's related to <version.immutables>2.8.8</version.immutables> property.

Additional context

N/A

[Rhys Arkins]

My understanding is that Maven versioning - unlike semver - does not specify that a version suffix automatically means it is unstable.

Can Renovate be configured to ignore this type of version? Yes

Should Renovate ignore this type of version by default? I would like to see some reference/specification before agreeing that this is a bug or something we should do as default behavior.

For example, Google's popular guava library has versions like 28.0-android. They are stable. Why would 2.8.9-ea-1 be assumed to be unstable?

[Rhys Arkins]

If we cannot conclude that Renovate has a way to reasonably determine such releases as unstable, then our matchCurrentVersion and allowedVersions package rule fields may be helpful, e.g. something like:

{
  "packageRules": [{
    "datasources": ["maven"],
    "matchCurrentVersion": "/^\\d+\\.\\d+\\.\\d+(-RELEASE)?$/",
    "allowedVersions": "/^\\d+\\.\\d+\\.\\d+(-RELEASE)?$/"
  }]
}

This way if the current version is semver-ish then it will only propose updates which are semver-ish

[Halil İbrahim Şener]

Ah, I thought Guava was the exception as you mentioned here #529 (comment). Then, it makes sense.

I am not sure about changing it globally because it might break others. I think I will add the following rule:

{
    packageNames: ['version.immutables'],
    allowedVersions: '!/^.+-ea-\\d+$/'
},

Alternatively, we can switch to semver for immutables dependencies. (Something like 'versioning': 'semver'). (I'll try this one first.)

[Rhys Arkins]

I still think it's a mistake for projects to version in this way, but I was informed by some from the Maven world that it's not a forbidden approach.

Re: your proposed rule, I think you'd be better to use packagePatterns. packageNames won't match the group name you have.

[Halil İbrahim Şener]

I still think it's a mistake for projects to version in this way, but I was informed by some from the Maven world that it's not a forbidden approach.

X.Y.Z-RC1 is very common but looks like there is a specific logic for that. Should we also accept ea as a release candidate here?

Re: your proposed rule, I think you'd be better to use packagePatterns. packageNames won't match the group name you have.

Check.

I have used the following rule then the PR (PicnicSupermarket/oss-parent#81) is autoclosed.

{
    packagePatterns: ['^org\\.immutables:.+$', 'version\\.immutables'],
    versioning: 'semver'
},

Thanks for the help @rarkins. 🙏

[Rhys Arkins]

Is EA a commonly used pre-release identifier? I forget if we got the list from maven's or we created it ourselves. We generally prefer to implement to spec but the spec is unfortunate in this case.

[Halil İbrahim Şener]

Is EA a commonly used pre-release identifier? I forget if we got the list from maven's or we created it ourselves. We generally prefer to implement to spec but the spec is unfortunate in this case.

There are some links at the top of the file. ea is not mentioned in https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification. So probably we should leave it out.

[Rhys Arkins]

Agreed. Thanks for checking that out.

[Halil İbrahim Şener]

Thank you.