Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <AD61DB16-A138-4811-9D84-C9B72932308D@dionne-associates.com>
References: 
 <CAJ_m3YCeLKDMFp3VvB4jsak0GAV8tU59J+Bjks4+Fs8+4c628A@mail.gmail.com>
	<CA+Y+444+pktHo-3g2Y8ieQ=oKbe-oE_BV_UbnnyqYWG0dYMxvg@mail.gmail.com>
	<6BC9C06A-D317-409F-83E8-F898CAB3A617@spy.net>
	<E10FB54E-8362-41DA-A5EA-6876BB5AC605@apache.org>
	<6B64ED84-544F-4C84-9DD4-D794AD025380@spy.net>
	<82F3E1E5-A9C7-4EC7-BEBF-E4BAD753AF85@gmail.com>
	<CAJ_m3YCcSUmD9gGxys2b+SMREUUV3n1iraKQ93Av5dzQOt0FMQ@mail.gmail.com>
	<4FD791CC-15A9-4FE9-97B6-76D1B2BD850C@spy.net>
	<CAJ_m3YAQYQ100OGG3VaKgagMnd47+EjgSjXBiV-UEcQ7ETHrwQ@mail.gmail.com>
	<CAOFYJNYuHjgmrfKRbQao9jEgs7SXcuVYPyTj2EvcJyCQY7HxQw@mail.gmail.com>
	<CAJ_m3YB9JSufjSkb708k2+tdma714pwjmjsAPVAy28sSm03VqQ@mail.gmail.com>
	<AD61DB16-A138-4811-9D84-C9B72932308D@dionne-associates.com>
Date: Fri, 21 Oct 2011 17:43:01 +0100
Message-ID: 
 <CABvT1DGbKV+CUzZsQoG=+kw0UzpaEr1omOyq0C6Uk3wnj__=0A@mail.gmail.com>
Subject: Re: Tweaking the release procedure
From: Robert Newson <rnewson@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

I'll also note that 'git pull --tags' will update any tags that have
changed, despite what the man page for git-tags actually says.

B.

On 21 October 2011 17:39, Robert Dionne <dionne@dionne-associates.com> wrote:
>
>
> On Oct 21, 2011, at 12:33 PM, Paul Davis 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.
>
> I think this is pretty common
>
>
>
>