Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
module.version values for SNAPSHOT project versions don't respect MMT's version order requirements #184
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 188.8.131.525201742 (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 184.108.40.2065201742, 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 220.127.116.115201742, 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.
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.