As pointed out by Benson, the whole skipping thing *should* be a non-issue anyway. If doing a release you should already know that it's good enough. You should already have tested it thoroughly on your own OSes. You should have already requested other devs to build from a hash/buildnumber and verify behaviour. You should already have deployed N snapshots for people to try and tweaked the code based on those results.
Given a proper community review BEFORE release the vote should be swift and straight forward because the result is already known. The caveat of this is that the master branch or svn trunk needs to be static with the exception of fixes to desired-to-be-resolved/new-found issues. However it seems to me that this is just proper anyway and already what happens, more or less. I agree with the don't skip X.Y.0, however my solution to that is: Be *very*careful! And the second solution is: If you happen to have X.Y.0 end up a bad apple, *that's life*, roll X.Y.1 and carry on. Do better next time. Fred. On Fri, May 31, 2013 at 11:22 AM, James Nord (jnord) <jn...@cisco.com>wrote: > > This discussion about respins is really strange to me. I've been cutting > > releases, with Maven, at Apache, for years now. And all of them have > reused > > version numbers for respins. And all of them have carefully used staging > > technology (old: directories, new: Nexus) to ensure that artifacts don't > > escape to the wild until they pass the vote. > > But they have to be in the wild in order to test (especially plugins). > > This adds a barrier to test for external people in a corporate > environment, and can cause mishaps if one library delivered with a plugin > is not cleaned up correctly from a MRM, causing the old failed version to > be served up to clients. > > Basically IMHO reusing version numbers violates maven rule #1 releases > never change. > > Personally I wouldn’t care if 3.3.0 is called 3.3.0-7 or 3.3.0-24 so long > as it is the official "3.3.0". > > After all isn’t this what the buildnumber is for? > > +1 no reusing version numbers (non binding) (but I am against skipping > x.y.z versions - e.g. there should not be a gap from 3.2.12 to 3.3.6 ) > > /James >
