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

Reply via email to