couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 16:38:49 GMT
If other projects jumped off a cliff, would couch? I, for one, say no.

B.

On 21 October 2011 17:33, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> 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
>>
>
> Are there projects that do this version incrementing when a vote
> fails? That's an idea I haven't heard before.
>

Mime
View raw message