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 00DC69603 for ; Wed, 19 Oct 2011 17:28:24 +0000 (UTC) Received: (qmail 15906 invoked by uid 500); 19 Oct 2011 17:28:23 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 15871 invoked by uid 500); 19 Oct 2011 17:28:23 -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 15863 invoked by uid 99); 19 Oct 2011 17:28:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Oct 2011 17:28:23 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Oct 2011 17:28:17 +0000 Received: by vcbfo11 with SMTP id fo11so2553049vcb.11 for ; Wed, 19 Oct 2011 10:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=ci/RkHUaOezvnm6eoBYahdCKXjz1hJ3bHhwpKEHwWhA=; b=Xp65uNXLmZ+TwqYfT8V/8IW47yiJo6XERFlMerIfsJccmNeY9YEcMXew+8bo935JsW 4W1ijYiiSsiwnGPMQJDofI5VetFYPt9iWzHOGSsquWlo3pzhMns/495IODGqByNwxsOG kmTOpNU2V4WnZcUK0Q34+hhNAbp/tlINKk8jM= Received: by 10.52.21.83 with SMTP id t19mr1878778vde.88.1319045276262; Wed, 19 Oct 2011 10:27:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.160.130 with HTTP; Wed, 19 Oct 2011 10:27:16 -0700 (PDT) In-Reply-To: References: From: Paul Davis Date: Wed, 19 Oct 2011 12:27:16 -0500 Message-ID: Subject: Re: Tweaking the release procedure To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd say its fine. As you point out it's just that we blessed the rc1. I'm guessing that's impossible to change given the GPG signature. On Wed, Oct 19, 2011 at 12:11 PM, Robert Newson wrote: > I like it, +1. > > I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a > little strange. It will be exactly the same as the '1.1.1rc1' tag, > including *saying* 'tag 1.1.1rc1' in the tag body (when you view it > with git tag -v 1.1.1, for example). I'm fine with that, it's pointing > at the same stuff and it's a record of the fact that rc1 was blessed > as the actual release, but I mention it because it's odd. > > B. > > On 19 October 2011 17:55, Paul Davis wrote: >> Devs, >> >> Now that we're on Git and have a system for managing tags that isn't >> nutty, its time that we should revisit our tagging protocol for >> releases. >> >> First, a note about the Git hosting. One of the ASF requests was that >> I write a thing that prevented the ability of rewriting history on >> master. When I implemented this I made the branch pattern configurable >> to multiple branches. Currently this protection applies to master, >> trunk, and any branch or tag prefixed with "rel/". The idea was that >> we'd be able to move release branches like 1.1.x, 1.2.x etc to >> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The >> same for tags. Once we tag something as rel/1.1.1 the rewrite checks >> will prevent someone from accidentally modifying it. >> >> So given that, and the fact that Git lets us alias specific tags >> exactly, I thought I'd propose a couple slight tweaks to the release >> procedure. >> >> 1. When tagging release candidates, the tag would be of the pattern: >> >> =A0 =A0 tags/rc/X.Y.Z-rcN >> >> 2. When a release formally passes a vote, we would copy the tag to: >> >> =A0 =A0 tags/rel/X.Y.Z >> >> 3. I think we discussed this before, but we should also place the rc >> artefacts into a directory named as such (IIRC, we decided that the >> name shouldn't change). Ie, 1.1.1 would be stored at: >> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.ta= r.gz >> >> 4. Making new release branches we should name them: >> >> =A0 =A0branches/rel/X.Y.x >> >> 5. For continuity, I'd also propose copying all of our older tags and >> branches to the new pattern (while keeping the current versions around >> for an extended period of time). >> >> Thoughts? >> >