Hi Sebastian, IMO avoiding point release is a mistake because you loose a strong statement regarding backward compatibility
+) commons-exec-1.0.0 is out but contains a stupid bug +) commons-exec-1.0.1 is ONLY a bugfix release adding absolutely no fatures +) commons-exec-1.1.0 contains the bugfixes but exposes more feature (and might accidently break a client) In short - a point release guarantees no deployment problems which is not the case for a new minor release. 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