+1 for pre-releases (RC, etc) -1 for actual releases (non-binding) /Anders
On Thu, May 30, 2013 at 8:20 AM, Hervé BOUTEMY <[email protected]>wrote: > I agree with Dan and Wayne > > +1 for "qualified" releases (alpha, beta, RC, etc…) that are working > toward the > full blow release but aren't intended to be that. > > -1 for the actual releases. > > And I don't care if the next 3.1.0-alpha is alpha-2 or alpha-4: what I > care is > that it is not alpha-1 any more since we're getting confused (votes, git > tag > copied in local copy) > > Regards, > > Hervé > > Le mercredi 29 mai 2013 14:52:45 Wayne Fay a écrit : > > Agree with Dan. > > +1 for qualified > > -1 for actual > > > > Wayne > > > > On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp <[email protected]> wrote: > > > +1 for "qualified" releases (alpha, beta, RC, etc…) that are working > > > toward the full blow release but aren't intended to be that. > > > > > > -1 for the actual releases. > > > > > > Dan > > > > > > On May 29, 2013, at 6:01 AM, Stephen Connolly > <[email protected]> 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-procedur > > >> e.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 > > > > > > -- > > > Daniel Kulp > > > [email protected] - http://dankulp.com/blog > > > Talend Community Coder - http://coders.talend.com > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
