maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [VOTE] Should we respin CANCELLED releases with the same version number?
Date Sun, 02 Jun 2013 19:11:15 GMT
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 != 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> wrote:
>> > >> 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 poor
>> > > 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 release
>> 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é
>> > >>
>> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit :
>> > >> > >but as I see, there seems to be a consensus around a 2-sided
rule:
>> > >> > >- 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
think
>> > that
>> > >> > the no re-spin rule should still apply in the same manner.
>> > >> >
>> > >> > -Chris
>> > >> >
>> > >> > On Sat, Jun 1, 2013 at 8:41 PM, Hervé 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
rule:
>> > >> > > - don't reuse version number for pre-releases (RC, etc)
>> > >> > > - reuse version number for actual releases
>> > >> > >
>> > >> > > Regards,
>> > >> > >
>> > >> > > Hervé
>> > >> > >
>> > >> > > Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit
:
>> > >> > > > 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
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
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> 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


Mime
View raw message