update-properties doesn't seem to respect allowMajorUpdates parameter

[fgabolde]

I'm writing a CI script to update properties that define versions to the latest stable version, but without breaking the build -- so major updates are not allowed.

mvn versions:update-properties -DallowMajorUpdates=false should be ideal for this, but it doesn't appear to work as advertised:

[INFO] Minor version changes allowed
[INFO] Updated ${lombok.version} from 1.18.2 to 1.18.22
[INFO] Minor version changes allowed
[INFO] Updated ${slf4j.version} from 1.7.13 to 2.0.0-alpha6
[INFO] Minor version changes allowed
[INFO] Updated ${junit.version} from 4.12 to 4.13.2

The lombok and junit updates are as expected, but the slf4j update is obviously a major version change!

The doc:

Whether to allow the major version number to be changed.

from http://www.mojohaus.org/versions-maven-plugin/update-properties-mojo.html#allowMajorUpdates

This is versions-maven-plugin:2.9.0:update-properties.

[pzygielo]

The doc:

Whether to allow the major version number to be changed.

the same doc:

Default: true

-DallowMajorUpdates = -DallowMajorUpdates=true => allow

What if you set it to false to disallow major updates?

[fgabolde]

Yes, sorry, that's what I've been doing. I will update the bug description to clarify this.

[pzygielo]

Getting similar (for artifact with the latest version in central 3.0.0-M5) result.

I'm pretty sure it's due to the fact, that every rc, m, alpha, beta, snapshot releases are still considered as < 3.0.0, which in my case is set as upper bound to update.

But if my project depends on org.codehaus.mojo:versions-maven-plugin, in version 1.3 (which has only final releases in central):

• with -DallowMajorUpdates=true property is updated to 2.9.0,
• with -DallowMajorUpdates=false property is updated to 1.3.1.
  which is all as expected.

Also see https://maven.apache.org/pom.html#Version_Order_Specification.

[pzygielo]

Similar:

• Impossible to restrict Major version number update - allowMajorUpdates=false is not respected #11
• allow* parameters not working on display-dependency-updates #299
  for the same reasons.

[fgabolde]

I'm pretty sure it's due to the fact, that every rc, m, alpha, beta, snapshot releases are still considered as < 3.0.0, which in my case is set as upper bound to update.

That is technically true, but wouldn't you agree that it would still constitute a major version update?

But if my project depends on org.codehaus.mojo:versions-maven-plugin, in version 1.3 (which has only final releases in central):

* with `-DallowMajorUpdates=true` property is updated to **2.9.0**,

* with `-DallowMajorUpdates=false` property is updated to **1.3.1**.
  which is all as expected.

Yes, this correct behavior is also what I've been seeing with other dependencies.

Also see https://maven.apache.org/pom.html#Version_Order_Specification.

I was vaguely aware of this but thanks for bringing it to my attention, it's very helpful. This part in particular:

Note: As 2.0-rc1 < 2.0, the version requirement [1.0,2.0) excludes 2.0 but includes version 2.0-rc1, which is contrary to what most people expect. In addition, Gradle interprets it differently, resulting in different dependency trees for the same POM. If the intention is to restrict it to 1.* versions, the better version requirement is [1,1.999999).

So I understand the technical reason why allowMajorUpdates (and others?) works like it does, but the allowMajorUpdates name doesn't communicate that it relies on this behavior -- the "major" part even implies that it should behave like I assume Gradle does.

I don't think you would break a lot by changing this behavior so that 2.0-rc1 is excluded from upgrades, as I don't think many users depend on it, in fact they would probably find it surprising. Failing that, maybe an additional parameter could control whether to use the current behavior or one where 2.0-rc1 would not be a valid target.

[pzygielo]

I'm pretty sure it's due to the fact, that every rc, m, alpha, beta, snapshot releases are still considered as < 3.0.0, which in my case is set as upper bound to update.

That is technically true, but wouldn't you agree that it would still constitute a major version update?

Yes, yes I would! I was surprised by the current behaviour as well.

[jarmoniuk]

This has been addressed in #753 which is already available in the latest release (2.13.0)

@slachiewicz please close