couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 22:06:41 GMT
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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message