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 wendallc@83864.com designates
 209.85.220.45 as permitted sender)
Sender: Wendall Cada <wendallc@83864.com>
Message-ID: <515A1AD2.1060808@apache.org>
Date: Mon, 01 Apr 2013 16:40:02 -0700
From: Wendall Cada <wendallc@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: dev@couchdb.apache.org
Subject: Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
References: <6760C936-9099-4031-9844-650F46A18341@apache.org>
In-Reply-To: <6760C936-9099-4031-9844-650F46A18341@apache.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

One item missing from this is support of existing versions. I'm not sure 
if a timeline exists for this, but it should be well understood what the 
support window will look like for old versions.

Wendall

On 03/30/2013 12:29 PM, Jan Lehnardt wrote:
> Hi all,
>
> It is time to think about how to square the upcoming changes to CouchDB and the next releases.
>
> Robert Newson and I hashed out this plan:
>
> 1. Compile a list of API changes between now and after the BigCouch merge (https://issues.apache.org/jira/browse/COUCHDB-1756).
> 2. Ship CouchDB 1.4.0 with a `X-CouchDB-Deprecated: true` header for features that will go away.
> 3. Ship CouchDB 2.0.0 with the API changes done, so it is API compatible with the BigCouch merge.
> 4. Merge BigCouch and ship that as 3.0.0.
>
> Spread over our new quarterly release schedule:
>
> Early April: 1.3.0.
> Early July: 1.4.0. With API deprecation warnings.
> Early October: 2.0.0. With API changes.
> Early January: 3.0.0. With BigCouch.
>
> Alternatively, we can ship 1.4.0 and 2.0.0 concurrently, so the BigCouch merge work doesn�t get a chance to get stale:
>
> Early April: 1.3.0.
> Early July: 1.4.0. With API deprecation warnings.
> Early July: 2.0.0. With API changes.
> Early October: 3.0.0. With BigCouch.
>
> Monthly minor- and patch-level-versions will continue as usual.
>
> If we want to ship new features before BigCouch but after 1.4.0, we can roll 1.5.0 / 2.1.0 before 3.0.0.
>
> Anything up to the BigCouch merge should be trivial, so we can be confident we get that right (modulo forgetting to deprecate something). If the actual technical issues to get BigCouch merged aren�t done by October in the way we are satisfied with shipping, we can wait to ship 3.0.0 until we think it is ready.
>
> In an ideal world, if 2.0.0 and BigCouch merge are API compatible, we *could* ship BigCouch in say, 2.5.0 or something, but I think the underlying things change enough to warrant a full major version increase.
>
> The only open question I�d have is how to square that against the ongoing work on bringing rcouch in. I hope Benoit can comment on this.
>
> Bikeshed away! :)
>
> Jan
> --
>