couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Tweaking the release procedure
Date Wed, 19 Oct 2011 17:11:04 GMT
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.


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