trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <>
Subject Re: [SUGGESTIONS] s/-unstable/-dev/ for 3.3.x release cycle
Date Sun, 10 Jun 2012 19:16:32 GMT
On 6/10/12 3:31 AM, Jan-Frode Myklebust wrote:
> On Sat, Jun 09, 2012 at 10:44:23AM -0600, Leif Hedstrom wrote:
>>> On a related note.. it would be nice if the release candidates could be
>>> tagged as release candidates (trafficserver-3.x.y-rc1), instead of having
>>> several versions of trafficserver-3.x.y.tar.gz floating around.
>> So that would then also be the final release name name (e.g.
>> trafficsever-3.3.0-rc1-dev)? I find that somewhat confusing,
> I agree, that looks ugly. I was mainly thinking about stable releaes.

We generally don't have that problem for stable. There are no "release 
candidates" per se, i.e. 3.1.4 is what will become 3.2. So in a sense, the 
3.1.4 release is the release candidate for v3.2.

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.

>> 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. This is normal procedure at 
Apache, we don't release artifacts that are not accepted in the vote. This 
is why I did a respin later for v3.1.4, since it now actually worked. In 
retrospect, I should have respun (is that a word?) as 3.1.5 seeing that this 
caused confusion.

> 	52bb0e0cfd595f48844e2463e3a531f19cf27ff9 would be 3.1.4
> 	886465e5cbaaf41e6486da265bc0cc6ddbe23933 would be 3.1.5
>> This has another problem though, which is that all Jira tickets have
>> to be renumbered on a respin (at least I would insist that they
>> should).
> It's not a respin. Lots of tickets were closed on 3.1.4, and some more
> on 3.1.5. If some user complains about problems with 3.1.4 it would be

Not true.  :)  There were no bugs for 3.1.5. In fact, there is no 3.1.5, and 
there never will be (I hope).

If I understand the proposals, 3.1.4 would have become released as 3.1.5, 
skipping 3.1.4 entirely, and we would therefore have had to relabel all 
3.1.4 bugs to be 3.1.5. This is not a huge problem, Jira lets you do that 
pretty easily, but it also means bumping other bugs (again, not a huge 
amount of work, and hopefully not something that happens frequently). As far 
as I can recall, we've only run into this release problem a couple of times 
in close to 20 releases.

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.


-- Leif

View raw message