Is that going to deal with versions such as 2.6-beta-9? As currently exist?
-Chris On Fri, Mar 14, 2014 at 8:25 PM, Baptiste Mathus <[email protected]> wrote: > 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 >
