Fred, you're the one who mentioned git in that post.
Please remember what stephen pointed out (which I thought was rather nicely
worded): [paraphrased]
The real release is the source bundle, and the tags are
merely a convienance to a developer.
-Chris
On Mon, Jun 3, 2013 at 10:44 AM, Fred Cooke <[email protected]> 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!
>
> On Mon, Jun 3, 2013 at 2:31 AM, Chris Graham <[email protected]> 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 <[email protected]> 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 <
> [email protected]
> > >
> > > > 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: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > >
> > > >
> > >
> >
>
