from a pure technical perspective, yes: a release is a release but from recent experience, making such difference between pre-releases and actual releases could give us some flexibility without much disturbance
from my experience, even if this question is not absolutely scm-specific, git brings us a new problem we didn't have with svn: once a tag is set on the canonical repo and replicated on developers' repos, it is not automatically updated if updated in the canonical but I may miss some git-fu once again... Regards, Hervé Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit : > >but as I see, there seems to be a consensus around a 2-sided rule: > >- don't reuse version number for pre-releases (RC, etc) > >- reuse version number for actual releases > > Not sure how I feel about that. > > alpha/beta/RCx etc, they are all still valid version nos, so I think that > the no re-spin rule should still apply in the same manner. > > -Chris > > On Sat, Jun 1, 2013 at 8:41 PM, Hervé BOUTEMY <[email protected]> wrote: > > yes, the vote for one unique rule is clearly "-1" > > > > but as I see, there seems to be a consensus around a 2-sided rule: > > - don't reuse version number for pre-releases (RC, etc) > > - reuse version number for actual releases > > > > Regards, > > > > Hervé > > > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit : > > > I will need to recheck the tally, but I think the result is -3 > > > > > > So looks like we will be reusing version numbers on respins > > > > > > On Wednesday, 29 May 2013, Stephen Connolly wrote: > > > > We have been using a policy of only making releases without skipping > > > > version numbers, e.g. > > > > > > > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc > > > > > > > > Whereby if there is something wrong with the artifacts staged for > > > > release, > > > > > > we drop the staging repo, delete the tag, roll back the version, and > > > > run > > > > > > again. > > > > > > > > This vote is to change the policy to: > > > > > > > > drop the staging repo, document the release as not released, and run > > > > with > > > > > > the next version. > > > > > > > > Under this new proposal, if the staged artifacts for 3.1.0 fail to > > > > meet > > > > the release criteria, then the artifacts would be dropped from the > > > > staging > > > > > > repository and never see the light of day. The tag would remain in > > > > SCM, > > > > and > > > > we would document (somewhere) that the release was cancelled. The > > > > "respin" > > > > > > would have version number 3.1.1 and there would never be a 3.1.0. > > > > > > > > This change could mean that the first actual release of 3.1.x might > > > > end up > > > > > > being 3.1.67 (though I personally view that as unlikely, and in the > > > > context > > > > of 3.1.x I think we are very nearly there) > > > > > > Please Note: > > http://maven.apache.org/developers/release/maven-project-release-procedure > > > > > > .html#Check_the_vote_resultsdoes not actually specify what it means by > > > > "the process will need to be restarted" so this vote will effect a > > > > change > > > > > > either outcome > > > > > > > > +1: Never respin with the same version number, always increment the > > > > version for a respin > > > > 0: Don't care > > > > -1: Always respin with the same version number until that version > > > > number > > > > > > gets released > > > > > > > > This vote will be open for 72 hours. A Majority of PMC votes greater > > > > that > > > > > > 3 will be deemed as decisive in either direction (i.e. if the sum is < > > > > -3 > > > > > > or > +3 then there is a documented result) > > > > > > > > For any releases in progress at this point in time, it is up to the > > > > release manager to decide what to do if they need to do a respin. > > > > > > > > -Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
