Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of bimargulies@gmail.com
 designates 209.85.214.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANWgJS4oqSbO75N=39-r_uWOD0U3T=MTUfLHG66hCwiMXZVk6A@mail.gmail.com>
References: 
 <CA+nPnMzj8=A1LB00tqguYFSdjfMUWj7cPnkb2Yy_PSvtaaju3w@mail.gmail.com>
	<4380700.BUPMelbiuR@herve-desktop>
	<CAJcKzHEtUi7tHYv7LEyFVJFJitQoiR=f1dy+6O9tSUo17k_zbQ@mail.gmail.com>
	<6202917.FYvOXXbUYt@herve-desktop>
	<CABZhLO8j-C4OkFAOj38hadB_PVqQLJjPRswcnebiCHvL7cd7aQ@mail.gmail.com>
	<CALhtWkf0etipt-BTb9AFp1GGbpz3HKrrGQCNWMxXsc66kSse0Q@mail.gmail.com>
	<CABZhLO8hTC5BZsW-ouuhZRO2FWwKCU4Te8gkoouQ+c+95Axk9A@mail.gmail.com>
	<CANWgJS4oqSbO75N=39-r_uWOD0U3T=MTUfLHG66hCwiMXZVk6A@mail.gmail.com>
Date: Sun, 2 Jun 2013 15:11:15 -0400
Message-ID: 
 <CALhtWkedmmgtE2MoQZMuCw+6+Pj7cqjEp5m0CY3wJmwjgM4y6A@mail.gmail.com>
Subject: Re: [VOTE] Should we respin CANCELLED releases with the same version
 number?
From: Benson Margulies <bimargulies@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks, Baptiste, that's the reference I was looking for.


On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS <bmathus@batmat.net> wrote:
> That link is for HTTPd.
> For Apache general guidelines, read
> http://www.apache.org/foundation/voting.html
> -1 are only vetos for "code modification", not "procedural" issues .
>
> Cheers
>
>
> 2013/6/2 Fred Cooke <fred.cooke@gmail.com>
>
>> Benson, read the rules:
>>
>> http://httpd.apache.org/dev/voting.html
>>
>> "*-1 *No, I *veto* this action."
>>
>> +1 + -1 !=3D 0
>>
>> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies <bimargulies@gmail.com
>> >wrote:
>>
>> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke <fred.cooke@gmail.com> wrot=
e:
>> > >> from my experience, even if this question is not absolutely
>> > scm-specific,
>> > >> git
>> > >> brings us a new problem we didn't have with svn: once a tag is set =
on
>> > the
>> > >> canonical repo and replicated on developers' repos, it is not
>> > automatically
>> > >> updated if updated in the canonical
>> > >>
>> > >
>> > > Git brings you no such "problem", it simply exposes your extremely p=
oor
>> > > practices... A tag should, and in any sane place is, permanent and
>> > > irrevocable.
>> > >
>> > > On another note, the veto by -1 vote mechanism is a great idea for a
>> > > release, but a terrible idea for a principle like this. For a releas=
e
>> it
>> > > requires a justification, for this it's just "my opinion" overriding
>> one
>> > of
>> > > Maven's core principals.
>> >
>> >
>> > Fred,
>> >
>> > Who says that anyone has a veto? As a principle of Apache, very few
>> > things are subject to veto, and I can't see how this would be one. If
>> > there's a clear majority of opinion in favor of burning versions,
>> > we'll start burning versions. I voted -1. I'll live with whatever
>> > outcome, but I'd live more happily with a more elaborated description
>> > of the resulting procedure. Like, where and how do we document these
>> > never-born releases, etc, etc.
>> >
>> > --benson
>> >
>> >
>> > >
>> > > Stagnation wins.
>> > >
>> > > Fred.
>> > >
>> > >
>> > >>
>> > >> but I may miss some git-fu once again...
>> > >>
>> > >> Regards,
>> > >>
>> > >> Herv=C3=A9
>> > >>
>> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a =C3=A9crit :
>> > >> > >but as I see, there seems to be a consensus around a 2-sided rul=
e:
>> > >> > >- don't reuse version number for pre-releases (RC, etc)
>> > >> > >- reuse version number for actual releases
>> > >> >
>> > >> > Not sure how I feel about that.
>> > >> >
>> > >> > alpha/beta/RCx etc, they are all still valid version nos, so I th=
ink
>> > that
>> > >> > the no re-spin rule should still apply in the same manner.
>> > >> >
>> > >> > -Chris
>> > >> >
>> > >> > On Sat, Jun 1, 2013 at 8:41 PM, Herv=C3=A9 BOUTEMY <
>> herve.boutemy@free.fr>
>> > >> wrote:
>> > >> > > yes, the vote for one unique rule is clearly "-1"
>> > >> > >
>> > >> > > but as I see, there seems to be a consensus around a 2-sided ru=
le:
>> > >> > > - don't reuse version number for pre-releases (RC, etc)
>> > >> > > - reuse version number for actual releases
>> > >> > >
>> > >> > > Regards,
>> > >> > >
>> > >> > > Herv=C3=A9
>> > >> > >
>> > >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a =C3=A9crit :
>> > >> > > > I will need to recheck the tally, but I think the result is -=
3
>> > >> > > >
>> > >> > > > So looks like we will be reusing version numbers on respins
>> > >> > > >
>> > >> > > > On Wednesday, 29 May 2013, Stephen Connolly 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 stag=
ed
>> > 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 f=
rom
>> > 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 cancelle=
d.
>> > 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, an=
d
>> 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-procedu=
re
>> > >> > >
>> > >> > > > > .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 vote=
s
>> > >> greater
>> > >> > >
>> > >> > > that
>> > >> > >
>> > >> > > > > 3 will be deemed as decisive in either direction (i.e. if t=
he
>> > sum
>> > >> is <
>> > >> > >
>> > >> > > -3
>> > >> > >
>> > >> > > > > or > +3 then there is a documented result)
>> > >> > > > >
>> > >> > > > > For any releases in progress at this point in time, it is u=
p
>> to
>> > the
>> > >> > > > > release manager to decide what to do if they need to do a
>> > respin.
>> > >> > > > >
>> > >> > > > > -Stephen
>> > >>
>> > >> -------------------------------------------------------------------=
--
>> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >>
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org