couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Tweaking the release procedure
Date Wed, 19 Oct 2011 17:28:36 GMT
Paul, +1 to the broad strokes, but I'm a little confused about the specifics.  Do you really
want branch names to start with "branches/" and tag names to start with "tags/"?  Or is that
just a bit of abstraction leakage from the git internals?

Branch names like rel/1.1.x for non-rewriteable release branches are fine by me.  Tags like
rc/1.1.1rc1 and rel/1.1.1 I'm not so excited about.  Are you trying to use those prefixes
to enforce that the tags are immutable?  If so, then I guess it makes sense, though maybe
we don't need to repeat ourselves and instead use rc/1.1.1-1.

Bob, I think it's a good thing that copying the accepted release candidate to the final release
tag preserves the relationship between the two things.  I don't find it off-putting at all.

Thanks for getting this discussion going guys.


On Oct 19, 2011, at 1:11 PM, Robert Newson wrote:

> I like it, +1.
> I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a
> little strange. It will be exactly the same as the '1.1.1rc1' tag,
> including *saying* 'tag 1.1.1rc1' in the tag body (when you view it
> with git tag -v 1.1.1, for example). I'm fine with that, it's pointing
> at the same stuff and it's a record of the fact that rc1 was blessed
> as the actual release, but I mention it because it's odd.
> B.
> On 19 October 2011 17:55, Paul Davis <> wrote:
>> Devs,
>> Now that we're on Git and have a system for managing tags that isn't
>> nutty, its time that we should revisit our tagging protocol for
>> releases.
>> First, a note about the Git hosting. One of the ASF requests was that
>> I write a thing that prevented the ability of rewriting history on
>> master. When I implemented this I made the branch pattern configurable
>> to multiple branches. Currently this protection applies to master,
>> trunk, and any branch or tag prefixed with "rel/". The idea was that
>> we'd be able to move release branches like 1.1.x, 1.2.x etc to
>> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
>> same for tags. Once we tag something as rel/1.1.1 the rewrite checks
>> will prevent someone from accidentally modifying it.
>> So given that, and the fact that Git lets us alias specific tags
>> exactly, I thought I'd propose a couple slight tweaks to the release
>> procedure.
>> 1. When tagging release candidates, the tag would be of the pattern:
>>     tags/rc/X.Y.Z-rcN
>> 2. When a release formally passes a vote, we would copy the tag to:
>>     tags/rel/X.Y.Z
>> 3. I think we discussed this before, but we should also place the rc
>> artefacts into a directory named as such (IIRC, we decided that the
>> name shouldn't change). Ie, 1.1.1 would be stored at:
>> 4. Making new release branches we should name them:
>>    branches/rel/X.Y.x
>> 5. For continuity, I'd also propose copying all of our older tags and
>> branches to the new pattern (while keeping the current versions around
>> for an extended period of time).
>> Thoughts?

View raw message