couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 09:28:05 GMT
Hi,

My 2c from the gallery. I'm not involved in CouchDB, so just making
general observations from the perspective of other Apache projects
interested in using Git.

On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> As Noah points out, there are ASF procedural issues that affect this
> discussion. Part of making a release involves getting community input
> on whether the release is a valid artefact. As such we need to be able
> to refer to these "not-release" sets of bytes.

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.

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 www.apache.org/dist as-is. Otherwise
the release candidate is just dropped and the next one made.

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.

BR,

Jukka Zitting

Mime
View raw message