Clarification to 2): Sonatype uses the x.y.z-b version scheme (dash, not underscore) which works with Maven's suggsted version syntax. This is also the syntax I use for all customers I work with and that use staging. The 'b' is the release build, which starts on '1' and is incremented for each new release.
Earlier we used to do RC builds (or at least Benjamin did so) which I found very good to test new core versions early. The drawback was that we had to respin to get rid of the 'RC' in the version. In any case, we've discussed this earlier and even voted on it I believe. Regardless of what one individual thinks is "the right way", I don't think it's cool to just ignore what has already been decided on. Personally I don't even see the problem re-using version numbers for Maven core releases. For plugin releases there is a much more likely to be some confusion though. /Anders On Wed, Feb 12, 2014 at 9:35 AM, Arnaud Héritier <aherit...@gmail.com>wrote: > Hi, > > I'm in favor to not reuse the version. Like many others I'm often lost > between intermediate and final versions (but we can see it also as a maven > dev and advanced users privilege/constraint too - thus applying to very few > people). > > We discussed about it many times and AFAIK we have 2 solutions to achieve > this : > > 1/ We just pass some minor versions like Apache Tomcat is doing ( > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many > "not released" versions). We announce only releases considered stable > (let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and > versions in Jira. Users will have to take care to append all release notes > of none stable version to know what we changed between two stables versions > (or we have to do it for them). > 2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it is > like Sonatype Nexus team is doing. We have distinct tags in our SCM > (3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable > version we publicly announce. In Jira we only have a 3.2.0 version and we > just reopen or add issues in it to track the release landing. For users > we'll just announce a 3.2.0 but the binary they'll have will be called > 3.2.0_2 for example. > > In both cases we will throw in the bin unstable releases. > > I like both approaches and prefer them compared to our current one. > Between both of them I would prefer the second one (transparent for users > and not difficult for us). > > WDYT ? > > Note : Even If I'm in favor of this change I really don't want to hold up > the current release which such debate/vote thus I think it may be better to > apply this change only for the next release depending of how many time all > active developers think they need to finalize the 3.2.0 release and launch > another vote. > > Arnaud > > > On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt <m...@talios.com> wrote: > > > On 12 Feb 2014, at 13:57, Benson Margulies wrote: > > > > > 3.2.0.1 :-) > > > > 3.2.0-patchlevel-1-GA. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier >
