2012/11/13 Manfred Moser <manf...@mosabuam.com>: > 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.. uhm this means plugins will be dependent of core releases in case of issues ? Perso I would prefer to avoid that and have a separate library with his own release cycle for that > > 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 >
-- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
