On 12 February 2014 08:35, 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 ? > I prefer any scheme where we do not reuse a version number *ever*. We can handle the JIRA problem by just moving the issues fixed in forward (or just renaming the version that wasn't released in JIRA) The version was never released therefore it doesn't exist. The only remnants would be the tag in SCM. If there are any users "confused" then we just tell them the answer "that version just didn't meet our release criteria"... The users will get over it... plugins or core... they will still get over it... they don't care what version number we give something once bigger numbers have more features and/or less bugs The only down side I can see is that we would be admitting that we have a quality bar... right now, unless you follow the dev list, it could seem that we don't do a lot of testing of releases - because you don't see all the (take 2) style votes. By skipping version numbers we would be saying "look here we do have a quality bar" and users would then be able to complain about how low that bar is with respect to their expectations... Still I would rather that kind of pressure from users and field questions like "what happened to 3.2.0?" than respin 3.2.0 That is my EURO 0.02 As always the chair will bow to the decision of the PMC committee! -Stephen > > 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 >
