Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Sun, 10 Jun 2012 22:17:17 +0200
From: Jan-Frode Myklebust <janfrode@tanso.net>
To: Leif Hedstrom <zwoop@apache.org>
Cc: users@trafficserver.apache.org
Subject: Re: [SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle
Message-ID: <20120610201717.GA21211@dibs.tanso.net>
References: <4FD25284.3020304@apache.org>
 <20120609145728.GA9547@dibs.tanso.net>
 <17A3DCFD-1B29-4F9F-AB73-86AC0C39300B@apache.org>
 <20120610093131.GA29001@dibs.tanso.net>
 <4FD4F290.9010404@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4FD4F290.9010404@apache.org>
User-Agent: Mutt/1.5.20 (2009-12-10)

On Sun, Jun 10, 2012 at 01:16:32PM -0600, Leif Hedstrom wrote:
> 
> For "patch" releases on a stable branch this problem could occur,
> but in that case, I'd suggest we simply skip failed releases. We've
> done this in the past, for example, 3.0.3 was never released if I
> recall (because it failed). So we went from 3.0.2 to 3.0.4.

Right, this is exactly what I'm asking for (or alterntively -rc* tags).

> >>If we are concerned about the reuse of the minor number during dev
> >>release recycles, I'd suggest we do what Nick proposed, and simply
> >>skip version numbers.
> >It's not skipping, it's bumping. The first 3.1.4 would still have been
> >released, but it would be a brown paper bag release..
> 
> No can do. It failed the vote (I canceled it), so that particular
> incarnation of 3.1.4 was not releaseable.

Ok, guess I'm talking about "tagged" not "released". I'm not
familiar with the apache release process. As I see it 3.1.4 was tagged
5 times as release candidates, and the final one was released. In
other projects I think we'd see 3.1.4-rc1, rc2, rc3, rc4 and rc5 which
eventually would be renamed to non-rc when it was officially released.

> 
> The more I read this though, and thinking about it, I'm pretty
> convinced that Nick's suggestion of bumping version numbers (which
> we've done at least once before) is the way to go.

Sounds good.


  -jf