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>: > >> 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 > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
