couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Tweaking the release procedure
Date Thu, 20 Oct 2011 17:51:34 GMT
On Wed, Oct 19, 2011 at 10:10 PM, Adam Kocoloski
<> wrote:
> On Oct 19, 2011, at 10:53 PM, Dustin Sallings <> wrote:
>> On Oct 19, 2011, at 6:56 PM, Adam Kocoloski wrote:
>>> I think you might be reading a bit too much into what Noah is saying here.  I
believe he's just taking issue with the two separate rc/ and rel/ "paths" in the tag names.
 For what it's worth I agree with him on that front, though I'd consider going even further
(as Paul suggested earlier in the thread) and just prevent rewriting of any tag pushed to
the ASF remote.  Then there's no need for any tag prefix at all.  Best,
>>    I don't think that's different from what I said.  Tags don't generally have
"paths" (it's 1.4rc1 or it isn't) and git makes it hard to overwrite them because it's a bad
idea and will only lead to confusion.
>>    IMO, there just isn't room or need to innovate here.  Code's cooked in various
dev branches.  That gets rolled up into an "official" branch towards a feature or release.
 Once a release is almost ready, alpha, beta and RC tags get dropped in aligned with the
same version numbers the server will report.  Once it's done, you can retag a commit with
a newer tag that calls it done and it's shipped.
>> --
>> dustin sallings
> Git makes it hard, but by no means impossible.  The whole reason these "paths" are even
on the table is to add some immutability to the official ASF repo.  A little less convention,
a little more configuration.  Best,
> Adam

Yes, the "path" prefixes (path probably was a bard word in my original
email) exists merely as a way to distinguish between "these are
official releases and are immutable" and the "this is a temporary tag
that I can fix if I screw up."

I'm trying to consider all the cases here (in the context of my OCD).
Do we necessarily care about the rc tags once a release has been made?
In a perfect world I would expect one tag per release and everything
would be neat and tidy. If so, then we need to be able to remove old
tags once they have been usurped by actual releases.

Consider it from the POV of a user as well. If you have 5-10 tags for
a release (not out of the question) then each user looking for that
release has to spend time figuring out which is the right tag. Which
means that either our naming conventions have to be extremely clear
(even then I've seen enough to know that we'll still get questions) or
we need to have procedure to narrow down the set of tags once the
release is made. I prefer procedure because it will minimize the
number of times in the future that i have to spend time debugging the
fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that
bug related to SpiderMonkey 1.7 and sealing.

View raw message