You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2013/05/29 13:23:58 UTC
[DISCUSS] [VOTE] Should we respin CANCELLED releases with the same
version number?
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.
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 <ga...@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.connolly@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: garydgregory@gmail.com | ggregory@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
>
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the
same version number?
Posted by Barrie Treloar <ba...@gmail.com>.
On 29 May 2013 20:53, Stephen Connolly <st...@gmail.com> wrote:
> The issue with that is when using the Maven Release Plugin, you will not be
...
Can't we fix the tooling then?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the
same version number?
Posted by Jeff Jensen <je...@upstairstechnology.com>.
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 <ga...@gmail.com>wrote:
> On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> 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 <ga...@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.connolly@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: garydgregory@gmail.com | ggregory@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
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the
same version number?
Posted by Fred Cooke <fr...@gmail.com>.
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 <
stephen.alan.connolly@gmail.com> 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 <ga...@gmail.com> wrote:
>
> > On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> 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 <ga...@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.connolly@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: garydgregory@gmail.com | ggregory@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
> > > >
> > >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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
> >
>
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the
same version number?
Posted by Stephen Connolly <st...@gmail.com>.
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 <ga...@gmail.com> wrote:
> On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> 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 <ga...@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.connolly@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: garydgregory@gmail.com | ggregory@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
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the
same version number?
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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 <ga...@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.connolly@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: garydgregory@gmail.com | ggregory@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
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@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