Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Not A Bug
-
Affects Version/s: 1.0
-
Fix Version/s: None
-
Labels:None
-
Number of attachments :
Description
Example
<version.xxx>1.0.24-rc3</version.xxx>
...
<property>
<name>version.adt-dml</name>
<dependencies>
<dependency>
<groupId>yyy</groupId>
<artifactId>xxx</artifactId>
<version>[1.0,2.0)</version>
</dependency>
</dependencies>
</property>
The latest release of xxx in my repository is 1.0.24-rc3.
The latest snapshot of xxx in my repository is 1.0.25-SNAPSHOT.
When I invoke update-properties with allowSnapshots=true my property is set to 1.0.25-SNAPSHOT. But when I invoke update-properties with allowSnapshots=false my property is not set back to 1.0.24-rc3 anymore. That worked in the version before release 1.0.
Update properties should never roll back a version. If you have advanced to a newer version and decide to go back, your SCM should be able to assist reverting to the previous version. The update goals are designed to move to newer versions.
Deciding what the previous version could be is actually a lot harder than you would think!
Deciding on the next version and the latest version is a little easier and is helped somewhat by the list of available versions.
We can infer rules about incrementing version numbers, ie 1.0.1.0 has possible next versions of 2.0.0.0, 1.1.0.0, 1.0.2.0, 1.0.1.1. Working backwards is a lot harder programatically, especially when you get down to the 0.0.1 version numbers....
In short, if you need to roll back either use versions:rollback, or scm, or edit by hand to a very early version and run update-properties again
update-properties will only ever modify the pom if it has a newer version to update with