I'm totally fine with the 1.0-RC0 1.0-RC1 1.0-RC2 == 1.0 thing, in Git you don't even have to copy anything ;-)
If you're going to do trial releases, then RCX is one good way to do it. I've got to point out, though, that "skipped numbers" means exactly NOTHING :-) You *always* skip numbers, by definition, every time you jump to a new version of a greater number in the next higher slot... eg: 1.1 1.2 1.3 1.4 1.5 1.6 2.0 < you missed 1.7 and 1.8, OMG :-p Fred. On Wed, May 29, 2013 at 1:54 PM, Stephen Connolly < [email protected]> wrote: > Ahh, so that is just a nicer way of handling the respin with same version > number. In any case we currently have a ∑ binding = 0 so no decision > forthcoming yet... but early days ;-) > > > On 29 May 2013 12:31, Gary Gregory <[email protected]> wrote: > > > On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly < > > [email protected]> wrote: > > > > > Moving discussion off the vote thread > > > > > > The issue with that is when using the Maven Release Plugin, you will > not > > be > > > voting on the released artifacts if you call it x.y.z-RCn, so you would > > > need a whole new vote for x.y.z. > > > > > > > The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the > > Nexus staging repo are marked x.y.z. > > > > Gary > > > > > > > > We could go all Eclipse nutjob and force the timestamp into every > > release, > > > e.g. > > > > > > 3.1.0.v20130529 > > > > > > But that way madness lies in my view... In any case, we will see where > > the > > > vote goes... and if there is a non-definitive answer, e.g. (-3 < ∑ > > binding > > > votes < 3) then we can see what alternatives fall out of the mix. > > > > > > > > > On 29 May 2013 12:10, Gary Gregory <[email protected]> wrote: > > > > > > > FWIW, over in Apache Commons land this is how we handle things. > > > > > > > > When we prepare and tag a release for version x.y.z, it is tagged as > > > > .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. > If > > > the > > > > [vote] fails, the tag stays as a record of what happened and the > email > > > > archives tell the story of why the vote failed. The next attempt is > > > tagged > > > > as > > > > .../x.y.z-RC2, and so on. > > > > > > > > Some of this is detailed here > > > > https://wiki.apache.org/commons/UsingNexusand here > > > > https://commons.apache.org/releases/prepare.html > > > > > > > > Gary > > > > > > > > > > > > On Wed, 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-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 > > > > > > > > > > > > > > > > > > > > > -- > > > > E-Mail: [email protected] | [email protected] > > > > Java Persistence with Hibernate, Second Edition< > > > > http://www.manning.com/bauer3/> > > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > > > Spring Batch in Action <http://www.manning.com/templier/> > > > > Blog: http://garygregory.wordpress.com > > > > Home: http://garygregory.com/ > > > > Tweet! http://twitter.com/GaryGregory > > > > > > > > > > > > > > > -- > > E-Mail: [email protected] | [email protected] > > Java Persistence with Hibernate, Second Edition< > > http://www.manning.com/bauer3/> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > Spring Batch in Action <http://www.manning.com/templier/> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > >
