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 Wed, 19 Oct 2011 17:27:16 GMT
I'd say its fine. As you point out it's just that we blessed the rc1.
I'm guessing that's impossible to change given the GPG signature.

On Wed, Oct 19, 2011 at 12: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