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
