Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
Date: Wed, 7 Nov 2012 23:15:09 +0000
Message-ID: 
 <CABvT1DH9fbkU-+cAgEE4as1sOrzJOMLEHDe4eO-csbC+VWszvw@mail.gmail.com>
Subject: 1.3 release branch
From: Robert Newson <robert.newson@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=089e011767ddd36ff604cdefe33e

--089e011767ddd36ff604cdefe33e
Content-Type: text/plain; charset=ISO-8859-1

All,

As I'm sure you've noticed, I cut a 1.3.x branch from master (b9af7ea)
yesterday. A legitimate question has arisen about how master and 1.3.x are
to be managed as we move towards the 1.3.0 release.

Obviously it is important than any work that lands on 1.3.x also lands on
master, though the inverse does not hold. For trivial bug fixes, I think
cherry picking works well. For larger things, and this is mainly, perhaps
only, about the CORS work, a feature branch is required, and that branch is
to be merged to both 1.3.x and master.

Going forward, all changes to master (and, in time, 1.4.x) will be from
feature or bug fix branches down to the various mainline branches. The
cherry-pick shortcut reflects our practice for this situation from the
Subversion days and is expedient.

With that said, not too much wil be landing on 1.3.x besides the CORS work
and a small collection of simple fixes. I'll finish by saying that anything
committed to 1.3.x that does not land on master will be considered release
blocking.

B.

--089e011767ddd36ff604cdefe33e--