Op Fri, 14 Mar 2014 10:25:59 +0100 schreef Baptiste Mathus
<[email protected]>:
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
Looks to me that the suffix has no influence on the calculation of dev and
rel versions, it's something which can be added later in the process as
well.
But correct me if I'm wrong :)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
