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?! +) assuming that the version numbering schema consists of three parts - why should I start with 1.0 and not with 1.0.0?! 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 Within Apache Commons a lot of projects are using a three part version number +) commons-dbcp +) commons-collections +) 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 +) consequently the very first version is 1.0.0 to be consistent +) it is up to the project lead to decide if an update of the minor or point release number is required +) 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