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 (nike.apache.org: domain of stephen.alan.connolly@gmail.com
 designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F1515400-BD0E-4DBE-B787-8AE393EFFEC8@tesla.io>
References: <5B52997E-0ABA-4CDC-8CCC-0C07538E363C@tesla.io>
	<CABZhLO9MwYdTWHBZK0KErQZt01yE80o-8qC4hCo0j1AnF6PGGA@mail.gmail.com>
	<2063674577806487039@unknownmsgid>
	<1379182855.45063.YahooMailNeo@web28905.mail.ir2.yahoo.com>
	<F1515400-BD0E-4DBE-B787-8AE393EFFEC8@tesla.io>
Date: Sat, 14 Sep 2013 20:47:58 +0100
Message-ID: 
 <CA+nPnMxUfQKgYPra7nEZpe0RKpwvmvK2NLH_9pLEt5ydEc-frg@mail.gmail.com>
Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7bb048227f992e04e65d3f17

--047d7bb048227f992e04e65d3f17
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Why as long as you don't push the tag, there's no big deal. Pushing the tag
is when problems appear... In any case I'd prefer to just skip failed
version numbers... Though I was voted down last time that came up, and
given I'm not running too many releases at the moment, I don't see my
opinion as being heavyweight on that subject... Version numbers are cheap
and we've had borked releases before (eg critical IMHO bugs in 2.1.0, 2.2.0
and 3.1.0...) so I don't buy the "what if a user checks out a tag that was
not released" argument.

In my opinion we need a release status page anyway, eg stating whether
specific versions are considered stabilising, stable, retired or advised
not to be used... Such a page would remove the need for recycling version
numbers *and* provide benefit to users at the same time.

But I will leave it for others to fight the relative costs of version
numbers (given the infinite supply) against making sure JIRA release notes
and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
there in the 3.3.0 release that 3.2.3 became, so no fix strictly
required) are correct and saving the risk that a user checks out an
unreleased tag and tries to build that from source and then starts trying
to raise bugs against a non-exist any version!

On Saturday, 14 September 2013, Jason van Zyl wrote:

> We need a slight modification of this strategy because the changes need t=
o
> be pushed somewhere so that people can examine the tag if they want durin=
g
> the release. I can't keep it on my machine until the vote passes.
>
> On Sep 14, 2013, at 2:20 PM, Mark Struberg <struberg@yahoo.de> wrote:
>
> > +1, that's what we also use in DeltaSpike and dozen other projects.
> > pushChanges=3Dfalse + localCheckout=3Dtrue for the win!
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > ----- Original Message -----
> >> From: Arnaud H=E9ritier <aheritier@gmail.com>
> >> To: Maven Developers List <dev@maven.apache.org>
> >> Cc:
> >> Sent: Saturday, 14 September 2013, 19:45
> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> G ood practice too. I'm using it also at work and we are doing our
> >> releases on dedicated branches.
> >>
> >> ---------
> >> Arnaud
> >>
> >> Le 14 sept. 2013 =E0 19:30, Fred Cooke <fred.cooke@gmail.com> a =E9cri=
t :
> >>
> >>> You're in Git now. You don't *have* to push your tag and release
> >> commits up
> >>> to the public world until AFTER you've checked they're OK. Or by
> >> failed
> >>> release do you mean voted down? They could live on branches until set
> in
> >>> stone, then merge --ff-only into master at that point, if so.
> >>>
> >>>
> >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <jason@tesla.io>
> >> wrote:
> >>>
> >>>> When a release fails like this it is annoying to have to rev back th=
e
> >>>> version of the POM. I'm not sure who flipped the versions in the
> >> POM and
> >>>> while it's a little more visible to see what you're moving
> >> toward I prefer
> >>>> the pattern of:
> >>>>
> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> >> 3.1-SNAPSHOT
> >>>>
> >>>> I know this may not be obvious to the casual observer as they may
> think
> >>>> 3.1 is next, but I'm personally fine with that.
> >>>>
> >>>> Especially after a failed release because then I don't have to go
> >> change
> >>>> all the POMs (whether rolling back manually, using the release
> >> rollback,
> >>>> the version:set command, or whatever else). It's much easier to
> >> just fix
> >>>> what's necessary and carry on.
> >>>>
> >>>> Unless anyone objects I would like to go back this pattern, what I
> >>>> previously had, because it's far easier to manage. Ideally it might
> >> be nice
> >>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
> >> lieu of
> >>>> that I would prefer not to diddle POMs after a failed release.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------


--=20
Sent from my phone

--047d7bb048227f992e04e65d3f17--