On Mon, 2015-07-27 at 14:43 +0200, Bertrand Delacretaz wrote: > Hi, > > On Mon, Jul 20, 2015 at 3:25 PM, Robert Munteanu <[email protected]> > wrote: > > On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote: > > > ... Although versions are cheap for us, it confuses our users > > > when > > > versions are > > > "missing". It's even more confusing that AEM 6.1 uses Sling i18n > > > 2.4.0 which > > > was _not_ released. So I'm for reusing here. > > > > +1 for reusing versions on cancelled votes... > > I am strongly against reusing version numbers when artifacts change. > > As soon as one creates a binary people can copy it around, there's no > way to know if that happens or not. > > Having two versions of an artifact with the same version numbers can > cause major confusion. Non-consecutive version numbers are not a > problem.
Thanks to all for the discussion. I've updated the release management page with the following text: Index: release-management.mdtext =================================================================== --- release-management.mdtext (revision 1693407) +++ release-management.mdtext (working copy) @@ -159,7 +159,7 @@ Be sure to include all votes in the list and indicate which votes were binding. Consider \-1 votes very carefully. While there is te chnically no veto on release votes, there may be reasons for people to vote \-1. So sometimes it may be better to cancel a release wh en someone, especially a member of the PMC, votes \-1. -If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*. +If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*. Note that any changes to the artifacts under vote require a restart of the process, no matter how trivial. When restarting a vote version numbers must not be reused, since binaries might have already been copied around. If the vote is successful, you need to promote and distribute the release - see *Promoting the Release*. Thanks, Robert
