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 Fri, 21 Oct 2011 23:52:00 GMT
On Oct 21, 2011, at 6:06 PM, Noah Slater wrote:

> On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <> wrote:
>> Here's another suggestion.
>> In all vote emails, we include the commit id that the release
>> artifacts were built from, but create no tag at all.
>> When the release passes the votes, we create the tag, with its final
>> name, against that commit id, and push it at the same time we upload
>> the artifact to the mirrors.
>> To obviate any concern about stale 1.1.1 tags in downstream repos, we
>> could, for this release only, add a 1.1.1-final tag as an unambiguous
>> tag, but only *after* the release is official.
>> Stated another way; we make each tag exactly once, and refer to the
>> build by its commit id until then. Since a commit id in git dictates
>> the precise state of the entire tree this is safe.
> I love it when something is so obvious you wonder why it wasn't apparent in
> the first place. I love this suggestion, and the specifics of how you
> communicate the git commit hash is unimportant. If there's a "describe"
> command to make it easier, so be it. We only tag when we mean to tag a
> release, for reals.
> As for the existing Git tags, I don't want to mess things up with a
> 1.1.1-final tag. Let's just accept the fact that some downstream
> repositories may have stale 1.1.1 tags from the previous two rounds, and go
> ahead and delete them. Once the vote passes on 1.1.1, we create a "1.1.1"
> tag as per this suggestion and request that people update their downstream
> git repos to make up for the fact we've now solidified our release procedure
> in a way that means those old tags need to be deleted. Make sense?

`git describe` would read something like 1.1.0-N-deadbeef, where N is the number of commits
since the last tag.  On .0 releases it would probably just be the commit hash since the commit
would not be a descendant of any tags.  It's a neat tool but I think it might confuse more
than illuminate.

I'm ambivalent about using the commit hashes directly.  I'd rather use the vote/ or -vote
style tags; I don't really share the concerns about cluttering up the tag namespace down the
line, and if it does get annoyingly cluttered I'm fine deleting the old vote tags.  But it
sounds like you find it to be pretty elegant, so I'm happy to go along.  Cheers,

View raw message