2014-03-13 19:19 GMT+01:00 Robert Scholte <[email protected]>: > To say it in your own words: IMHO I think you're wrong here ;) > > Version policy is about calculating the next version based on an input > version. > These are valid examples: > default policy: > getReleaseVersion("1-SNAPSHOT") = 1 > getReleaseVersion("1.0-SNAPSHOT") = 1.0 > getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0 > getDevelopmentVersion("1") = 2-SNAPSHOT > getDevelopmentVersion("1.0") = 1.1-SNAPSHOT > getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT > > odd-even > getReleaseVersion("1.0-SNAPSHOT") = 1.1 > getDevelopmentVersion("1.1") = 1.2-SNAPSHOT > > the metadata gives the following opportunity: > suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case > you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 -> > 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT > > I think it's weird to depend the policy on the GAV. Just choose a proper > policy for your project. >
FWIW, I'm also interested by this feature to further standardize our release process. And we'd ideally need at least the artifactId to be able to calculate the next developmentVersion. To make it short, the suffix of our artifactIds describe if it's an internal implementation project, or if it's an globally visible interface. In the second case, since this is a publicly published/used, the versioning is not the same and kind of more agressively checked (which seems similar to what Simone is describing in their bytecode analysis approach). HTH -- Baptiste
