module.version values for SNAPSHOT project versions don't respect MMT's version order requirements #184
Comments
|
From peter.mo...@alfresco.com on May 21, 2014 10:53:40 The leiningen AMP plugin faced exactly this issue, and resolved it by converting SNAPSHOT versions into "1 less" than the stated version (solution here: https://github.com/pmonks/lein-amp/blob/master/src/leiningen/amp/impl.clj#L53 ). For example project version 1.1.0-SNAPSHOT becomes module version 1.0.999, which clearly preserves the numerical ordering MMT requires (1.0.999 < 1.1.0). Note: this approach has a risk of collisions if a given module ends up with an actual released project / module version of 1.0.999. This is why base-one-thousand was chosen for the "1 less" calculation, and a higher base could be selected if the collision risk is perceived as being too high. |
|
From colum...@gmail.com on June 10, 2014 05:44:30 Labels: Milestone-Release-sdk-2.0.0 |
|
From colum...@gmail.com on July 17, 2014 06:22:30 Issue 69 has been merged into this issue. |
|
From colum...@gmail.com on July 17, 2014 06:31:13 Status: Accepted |
|
Working with @covolution to progress on the original issue (https://issues.alfresco.com/jira/browse/ENH-1232) and not having to hack around in the SDK. Keep you posted. |
|
Looks like this bug is starting to come home to roost: https://issues.alfresco.com/jira/browse/ACE-5006 ... |
|
Fixed |
From peter.mo...@alfresco.com on May 21, 2014 13:49:56
When constructing an AMP from a SNAPSHOT version of a project, the alfresco-maven-plugin replaces the -SNAPSHOT suffix with an auto-generated timestamp (since MMT doesn't support non-numeric version numbers - see https://issues.alfresco.com/jira/browse/ENH-1232 for more details on this bug in MMT). So for example, a project version of 1.1.0-SNAPSHOT might result in a module version of 1.1.0.1405201742 (or similar - the final version number component varies as its an auto-generated timestamp).
When the developer is preparing a non-snapshot build, they will remove the -SNAPSHOT suffix from the project version, and the alfresco-maven-plugin will no longer append a timestamp. So for example, a project version of 1.1.0 results in a module version of 1.1.0 (no change).
The problem comes about when that non-SNAPSHOT build is deployed to a server that already has the SNAPSHOT build installed. By default, MMT will block installation of an AMP that has a numerically lower version (reading left to right) version than the currently installed version.
Using the examples above, we can see that the SNAPSHOT build has a module version of 1.1.0.1405201742, but the released version (which is, in fact, newer) has a module version of 1.1.0, which MMT considers to be older (1.1.0 is numerically less than 1.1.0.1405201742, reading the digits left to right).
A solution must ensure that the numerical ordering requirement of the current shipping versions of MMT are met, across both SNAPSHOT and non-SNAPSHOT project versions.
Original issue: http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=184
The text was updated successfully, but these errors were encountered: