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 18:07:27 GMT
On Fri, Oct 21, 2011 at 10:28 AM, Jukka Zitting <>wrote:

> I'd say that's a perfectly valid use of tags. An official release
> should be backed by a tag, but there's no requirement for the reverse.
> Using tags for release candidates or other milestones should also be
> fine. It should be up to each project to decide how they want to name
> and manage tags.

That depends. As far as I understand it from this thread, once you create a
tag, downstream repositories are likely to keep those tags around. So, is it
unreasonable to assume that temporary tags will start to accumulate in this
downstream repositories?

The problem here is in communicating to the end user which tags correspond
to officially blessed release artefacts. With Subversion, you just delete
the tag and recreate it, and there is no chance of confusion. Is
this possible with Git? We absolutely cannot allow any situation where a tag
corresponding to a failed vote is presented to the user along-side tags
corresponding to officially blessed release artefacts. And as far as I am
concerned, that needs to take in to account any behaviour of the Git
downstream repositories that people may be using.

I also find the idea of renaming a release tag after the vote
> completes a bit troublesome. The way I see it, a release manager will
> tag a given state of the source tree and use that tag to build the
> release candidate. After that no repository changes should be required
> regardless of the result of the release vote. If the vote passes, the
> candidate packages are pushed to as-is. Otherwise
> the release candidate is just dropped and the next one made.

This only holds if there is a way to remove the failed tags. Either by
overwriting them, as we did with Subversion, or removing them in way that
removes them from another downstream repositories that users may be using.
If there is no way to do this, and my concern is shared by the community,
then we may have to adopt a procedure that involves "moving" a tag to a
blessed directory when the vote passes.

> This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
> If each release candidate is given a separate new tag and version
> number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
> which build is being tested. Version numbers are cheap.

Version numbers are only cheap if you're prepared to dilute what they mean.
At the moment the bugfix version number has a very precise meaning, and
there is a contract in place for when it is updated. Doing what you suggest
breaks that contract. I may not have mentioned this before, but I designed
the CouchDB versioning scheme, and I based it directly on the Apple
versioning scheme.

Read more about it here:

Also, this doesn't solve our problem of failed vote tags persisting in
downstream repositories.

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