maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Graham <chrisgw...@gmail.com>
Subject Re: [VOTE] Should we respin CANCELLED releases with the same version number?
Date Mon, 03 Jun 2013 01:30:31 GMT
On Mon, Jun 3, 2013 at 10:52 AM, Benson Margulies <bimargulies@gmail.com>wrote:

> On Sun, Jun 2, 2013 at 8:44 PM, Fred Cooke <fred.cooke@gmail.com> wrote:
> > Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
> > came to the conclusion that I thought this was anything to do with Git.
> > Subversion tags, though mutable, should not EVER be committed against or
> in
> > any other way modified.
>
>
>  Doing so is the behaviour of a (bad quality) grad
> > student, not a software development professional!
>
> Fred,
>
> Do you realize that those are, ahem, 'fighting words'? That this
> development community, along with a slew of other Apache communities,
> have treated this as a good practice for years? The net effect is that
> you calling us all unprofessional idiots.
>
> We may eventually change over to your preferred methodology, but
> insulting us wholesale is not, in my opinion, a very effective way to
> move opinion in your direction.
>
> Our policy has been that we want the SVN/scm tag to be one-to-one with
> the voted source which is one-to-one with the Maven metadata. Deleting
> and creating tags is consistent with that policy so long as we don't
> modify them thereafter. And we don't.
>
>
Benson,

Nicely worded.

And thanks for pointing out the " so long as we don't modify them
thereafter. And we don't." bit.

That is the well understood process, one that I think is valuable (as we
all understand [and adhered too]).

-Chris

--benson
>
>
>
>
> >
> > On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <chrisgwarp@gmail.com>
> wrote:
> >
> >> Fred,
> >>
> >> We are talking more process here. Not the specifics of an individual
> SCM,
> >> not everything is in git. We are still talking about the abstraction api
> >> that the maven-scm handlers provide, of which git is but one.
> >>
> >> -Chris
> >>
> >>
> >> On Mon, Jun 3, 2013 at 4:42 AM, 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.
> >> >
> >> > 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message