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.
Cheers,
-- Leif
