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:33:44 GMT
On Wed, Oct 19, 2011 at 12:28 PM, Adam Kocoloski <> wrote:
> 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?

Sorry, yeah. Before I had those it was a bit confusing between
"rel/1.1.1" and "rel/1.1.x" where one is actually an internal name of
"refs/tags/rel/1.1.1" and the other is "refs/branches/rel/1.1.x". Just
wanted to make that more apparent.

> 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.

Well, the rel/ prefix is for the pattern match to enforce the
non-rewriting part. The rc/ is just convention and would  be
rewritable. Or we could just disallow rewriting of any tag and then
have "1.1.1-rc1" "1.1.1-rc2" "1.1.1" etc etc. I don't have a huge
investment in the rel/ prefix by any means. Was just considering that
we have the capability so wondering if people would want to use it.

> 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.
> Adam
> 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