It seems that most people care about X.Y and X.Y.Z numbers of the versioning scheme, not X.Y.Z.N. To spin through version numbers without concern during release candidates, perhaps using the 4th position, N, would then allow continued use of the familiar X.Y and X.Y.Z references? Major.Minor.Point/bug.RC. It's arbitrary precision, but maintains the X.Y.Z format, and Z doesn't have "skipped numbers".
On Wed, May 29, 2013 at 6:31 AM, 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 >
