On 31 May 2013 10:22, 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 ) >
Can you please explain that last bit? If there is an API change (backwards compatible) that necessitates the next version after 3.2.12 have a minor version incremented and then it turns out that it takes another 7 tries to get a viable release out the door then that means that the released versions you would see (with no re-using) would be 3.2.12 and then 3.3.6. If you allow for reusing, you would get 3.2.12 followed by 3.3.0... perhaps you could explain what you are exactly against and how such a situation could arrise? > > /James >
