+1 if it helps to have more regular releases (but I'm not sure it will help)
On Wed, May 29, 2013 at 1:10 PM, Gary Gregory <garydgreg...@gmail.com>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 < > stephen.alan.conno...@gmail.com> 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: garydgreg...@gmail.com | ggreg...@apache.org > 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 > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
