+1, big fan of Semantic Versioning. Keeping the version string consistent hammers in that we follow semver rules. I think Maven plugins generally do anyway. :)
As for Maven plugins the API is generally the goals and <configuration> (and associated files, e.g. assembly xml) rather than the Java API. So example: adding new goal? Bump minor version. Removing a key from configuration? Bump major version. Changing default phase? I would say minor. Fixing bugs is patch, unless fixing means breaking behaviour. Changing a plugin's Class name or removing a method? This is almost always implementation detail, so in theory patch, but we can say minor version. On 6 May 2016 9:00 p.m., "Karl Heinz Marbaise" <[email protected]> wrote: Hi to all, I would like to suggest to keep the version number of the plugins and shared components to the following format (and may be also things we are using like plexus?): Major.Minor.Patch(-SNAPSHOT): (Following SemVer.org): So adding a new functionality which will not break the 3.0.X parts...so you can upgrade without breaking...for example: 3.0.23 now adding a new functionality which does not influence the older one should be: 3.1.0 So we should prevent changing it to: 3.1 So introducing a break in API must change the Major version and would look like this: 4.0.0 and 4.0 So consistently using a three number form Major.Minor.Patch .. Othwerise it's not a clear line from the user perspective...At the moment we have the chance to make things better than in the past... WDYT ? Kind regards Karl Heinz Marbaise --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
