On 24/02/2009, Siegfried Goeschl <siegfried.goes...@it20one.at> wrote: > Hi folks, > > I think you lost me .... > > +) assuming that commons-exec-1.0.0 is out there what would be the > version number for a bugfix only release - would it be 1.1?!
1.0.1 - for a point release 1.1 for a minor release But the first release would be 1.0. > +) assuming that the version numbering schema consists of three parts - > why should I start with 1.0 and not with 1.0.0?! Because the trailing .0 is optional. > Within the Apache community there is strong consensus regarding a three > part version numbering schema when looking at the official documentation > > +) http://apr.apache.org/versioning.html > +) http://commons.apache.org/releases/versioning.html This says that the .0 point release is optional. > > Within Apache Commons a lot of projects are using a three part version > number But mainly where there is a two-part release preceeding it: > +) commons-dbcp The archive site has: 1.0, 1.1, 1.2, 1.2.1, 1.2.2 > +) commons-collections 1.0, 2.0, 2.1, 2.1.1, 3.0, 3.1, 3.2, 3.2.1 > +) commons-daemon > +) commons-fileupload > +) commons-httpclient > +) commons-io > +) commons-logging > +) commons-net > So me reasoning is > > +) having a three part version number is a sensible approach Agreed. > +) consequently the very first version is 1.0.0 to be consistent Disagree; it's not necessary to use 1.0.0; 1.0 will do just as well. > +) it is up to the project lead to decide if an update of the minor or > point release number is required Well, there are rules for what constitutes a point release, but if one is needed, then by all means create 1.0.1 or 1.0.2 etc. > +) and yes, I'm rocking the boat .... :-) > Cheers, > > > Siegfried Goeschl > > > Luc Maisonobe wrote: > > sebb a écrit : > > > >> On 24/02/2009, Siegfried Goeschl <siegfried.goes...@it20one.at> wrote: > >> > >>> Hi Sebastian, > >>> > >>> IMO avoiding point release is a mistake because you loose a strong > >>> statement regarding backward compatibility > >>> > >> But there is nothing here to be compatible with ... > >> > >> > >>> +) commons-exec-1.0.0 is out but contains a stupid bug > >>> > >> That should be 1.0 > >> > > > > I second that. > > > > > >>> +) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no > fatures > >>> > >> Agreed. > >> > >> > >>> +) commons-exec-1.1.0 contains the bugfixes but exposes more feature > >>> (and might accidently break a client) > >>> > >> That would be 1.1 > >> > > > > I second that too. > > > > Very often, product versioning seems to be afraid of incrementing a > > number. This was clearly visible in Sun products (Solaris and Java) when > > they finally drop the first digits when they realize they don't mean > > anything anymore. The worst case is Perl, I don't even remember the > > number intermediate non-sense 0 digits that were put between the leading > > '5' and the final release digits, as if 5.1, 5.2 was too frightening. > > > > So a simple 2 digits scheme is far enough for many cases. > > > > Luc > > > > > >>> In short - a point release guarantees no deployment problems which is > >>> not the case for a new minor release. > >>> > >> Exactly. > >> > >> > >>> Cheers, > >>> > >>> > >>> Siegfried Goeschl > >>> > >>> > >>> sebb wrote: > >>> > On 24/02/2009, Siegfried Goeschl <siegfried.goes...@it20one.at> wrote: > >>> > > >>> >> Hi folks, > >>> >> > >>> >> the current feedback requires a cancellation and a discussion > >>> >> > >>> >> 1) wrong download link in email - was a copy and paste error on my > side > >>> >> > >>> >> 2) improved manifest in sources and javadoc jar - seems to be a > parent > >>> >> pom issue and effects all M2 releases (checked commons-cli, > >>> >> commons-digester, commons-io, commons-jxpath) > >>> >> > >>> >> 3) wrong versioning schema, e.g. "commons-exec-1.0.0" - according to > >>> >> http://commons.apache.org/releases/versioning.html the versioning is > >>> >> either correct or the docs are wrong > >>> >> > >>> > > >>> > I had not seen that. However, as far as I can tell, hardly any of the > >>> > other commons components uses the final [.0]. Only NET seems to have > >>> > started with 1.0.0. > >>> > > >>> > As I understand it, point releases are used for minor updates to an > >>> > *existing* release. E.g. Commons Lang released 1.0 and then 1.0.1. > >>> > > >>> > So although it appears to be allowed by the document, I think it would > >>> > be better to reserve the point marker for point releases. > >>> > > >>> > > >>> >> 4) missing findbugs-exclude-filter.xml - well, that's a blocker > >>> >> > >>> >> > >>> >> So the open questions are .... > >>> >> > >>> >> ad 2) any quick ideas how to fix that? I will dig though the parent > pom > >>> >> otherwise ... > >>> >> > >>> >> ad 3) can we agree an ONE schema which is properly documented - I'm > fed > >>> >> up with some undocumented guidelines resulting in not enough +1 to > get > >>> >> commons-exec out of the door, e.g. groupId or versioning. I propose > we > >>> >> find a common understanding which I put into the commons wiki. > >>> >> > >>> > > >>> > If there are any clarifications to be made, the versioning guidelines > >>> > document needs to be updated, not the wiki. > >>> > > >>> > > >>> >> Cheers, > >>> >> > >>> >> Siegfried Goeschl > >>> >> > >>> >> Siegfried Goeschl wrote: > >>> >> > Hi folks, > >>> >> > > >>> >> > the next release candidate .... > >>> >> > > >>> >> > Tag: > >>> >> > > >>> >> > > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0 > >>> >> > > >>> >> > Site: > >>> >> > > >>> >> > > http://people.apache.org/builds/commons/exec/1.0.0/RC4/site/index.html > >>> >> > > >>> >> > Binaries: > >>> >> > > >>> >> > > http://people.apache.org/builds/commons/exec/1.0.0/RC4/staged/commons-exec/commons-exec/1.0.0/ > >>> >> > > >>> >> > [ ] +1 release it > >>> >> > [ ] +0 go ahead I don't care > >>> >> > [ ] -1 no, do not release it because > >>> >> > > >>> >> > > >>> >> > Let the fun begin ... > >>> >> > > >>> >> > Siegfried Goeschl > >>> >> > > >>> >> > PS: The test distribution is not part of the release but handy for > >>> >> > platform testing - > >>> >> > http://people.apache.org/~sgoeschl/download/commons-exec/ > >>> >> > > >>> >> > > --------------------------------------------------------------------- > >>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> >> > For additional commands, e-mail: dev-h...@commons.apache.org > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > >>> >> > --------------------------------------------------------------------- > >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> >> For additional commands, e-mail: dev-h...@commons.apache.org > >>> >> > >>> >> > >>> >> > >>> > > >>> > --------------------------------------------------------------------- > >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> > For additional commands, e-mail: dev-h...@commons.apache.org > >>> > > >>> > > >>> > > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
