Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 335AF96B2 for ; Fri, 21 Oct 2011 16:38:52 +0000 (UTC) Received: (qmail 44030 invoked by uid 500); 21 Oct 2011 16:38:51 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 43995 invoked by uid 500); 21 Oct 2011 16:38:51 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 43987 invoked by uid 99); 21 Oct 2011 16:38:51 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2011 16:38:51 +0000 Received: from localhost (HELO mail-yw0-f52.google.com) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Oct 2011 16:38:51 +0000 Received: by ywm39 with SMTP id 39so2099732ywm.11 for ; Fri, 21 Oct 2011 09:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.146.195 with SMTP id k3mr26258311icv.13.1319215130408; Fri, 21 Oct 2011 09:38:50 -0700 (PDT) Received: by 10.231.43.134 with HTTP; Fri, 21 Oct 2011 09:38:49 -0700 (PDT) In-Reply-To: References: <6BC9C06A-D317-409F-83E8-F898CAB3A617@spy.net> <6B64ED84-544F-4C84-9DD4-D794AD025380@spy.net> <82F3E1E5-A9C7-4EC7-BEBF-E4BAD753AF85@gmail.com> <4FD791CC-15A9-4FE9-97B6-76D1B2BD850C@spy.net> Date: Fri, 21 Oct 2011 17:38:49 +0100 Message-ID: Subject: Re: Tweaking the release procedure From: Robert Newson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 If other projects jumped off a cliff, would couch? I, for one, say no. B. On 21 October 2011 17:33, Paul Davis wrote: > On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting 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 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. >