+1 version incrementing logic should be a shared component not a part of core.
Also I wonder if we shouldn't formalise the ability to scope versioning systems per groupId:artifactId though that could merit being part of core... And is somewhat political too On Wednesday, 14 November 2012, Hervé BOUTEMY wrote: > no > core only needs to compare version > core never need to calculate "next" version > > some plugines like release or versions need to try to guess which is the > next > one: nothing that belong to core IMHO > > Regards, > > Hervé > > Le mardi 13 novembre 2012 14:28:18 Manfred Moser a écrit : > > True... separate, but closely related. If we state that semver is the > > recommended practice (and I believe that to be a good idea) .. the whole > > tooling should work nicely with it. And that includes the use case I > > mentioned.. > > > > And yes.. maybe the version stuff should be part of core ... and then be > > used e.g. by the release plugin as well as the versions plugin and > > others.. > > > > manfred > > > > On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote: > > > These are 2 separate issues. As long as the bugfix/patch-part contains > > > non-numeric values and Maven (actually Aether) still does a String > match > > > (apart from those special cases like alpha, beta, RC) we have to be > very > > > careful with calculating the next version. > > > You could question if this kind of logic belongs in the > > > maven-release-plugin, since it is more related to how Maven resolves > > > versions. > > > > > > Robert > > > > > > Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser > > > > > > <manf...@mosabuam.com <javascript:;>>: > > >> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote: > > >>> This is a long-standing issue, but I think a document and standard > has > > >>> emerged that I think is reasonable. How do people feel about trying > to > > >>> adhere to: > > >>> > > >>> http://semver.org > > >>> > > >>> and moving toward using this as our standard versioning > documentation? > > >> > > >> I think that would be awesome. One of the things we would have to do > is > > >> fix the release plugin to work with 1.2.3-RC.2 as compared to > 1.2.3-RC2. > > >> Currently it does not correctly suggest the next version being > > >> 1.2.3-RC.3 > > >> but rather goes to 1.2.4-RC.2 > > >> > > >> This would also make it easier to explain the reasoning for the > version > > >> numbering since we could just point to the external docs as a best > > >> practice. > > >> > > >> manfred > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org<javascript:;> > > >> For additional commands, e-mail: dev-h...@maven.apache.org<javascript:;> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org<javascript:;> > > > For additional commands, e-mail: dev-h...@maven.apache.org<javascript:;> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > > For additional commands, e-mail: dev-h...@maven.apache.org<javascript:;> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> > >
