I had created a hack of the clirr plugin at a prior employer to compute the next version number a few years ago.... (rejected by the mojo project, as the owners didn't want to start breaking builds with clirr)
We had 50-60 jars and 20+ developers with a range of skill/java knowledge, some remote. I attempted to use sigtest instead as a plugin for the enforcer but ran out of time/energy and switched jobs... but it's api was more than painful and getting useful info about the deltas was more than a little difficult. I understand the netbeans guys have pulled it off though. The general behavior of the clirr hack was to download the last release with a version number less then the projects (usually broke the build if the version had already been released) and run clirr, again breaking the build if the version didn't conform to what a few heuristics on top clirr expected. Of course this has limitations. An API that expects you to implement an interface (never too hot of an idea) to interact with the API needs to have that interface treated differently than if it was an interface clients were expect to call and not implement. My finding at every org I've been is that people screw up correct version number incrementing (including myself). Changing the type input on a method (unless its to a super class) breaks backwards compatibility, and refactoring tools makes doing this all too easy. Not sure how far you guys want to go with this, but I wouldn't mind putting in some effort or resurrecting the support for clirr. If maven embraces a standard like semver, building out even a partial enforcement of the standard would go a long way to further adoption. As far a version numbers stored in artifacts, perhaps allow an extension to the build that turns on the restriction, and maybe a corresponding enforcer rule? Rex On Wed, Nov 14, 2012 at 4:13 PM, Manfred Moser <manf...@mosabuam.com> wrote: > Sure... not core then. But ideally some shared library that implements > that so all plugins that need to do it can do it consistently the same.. > > manfred > > On Wed, November 14, 2012 3:17 pm, 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>: > >> >> 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
