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: <515A1AD2.1060808@apache.org>
References: <6760C936-9099-4031-9844-650F46A18341@apache.org>
	<515A1AD2.1060808@apache.org>
Date: Tue, 9 Apr 2013 23:37:43 +0100
Message-ID: 
 <CAPaJBx6XbYSGsbitoexcYEyUBxJW+v48EQhBNanryS584n3UjQ@mail.gmail.com>
Subject: Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
From: Noah Slater <nslater@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=f46d0447a291a553b604d9f533ab

--f46d0447a291a553b604d9f533ab
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think our roadmap process answers this:

http://wiki.apache.org/couchdb/Roadmap_Process

Let me know if you think we need something more than this...


On 2 April 2013 00:40, Wendall Cada <wendallc@apache.org> wrote:

> 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 merg=
e
>> (https://issues.apache.org/**jira/browse/COUCHDB-1756<https://issues.apa=
che.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=92t 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=92t done by Octo=
ber
>> in the way we are satisfied with shipping, we can wait to ship 3.0.0 unt=
il
>> 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=92d have is how to square that against the ongo=
ing
>> work on bringing rcouch in. I hope Benoit can comment on this.
>>
>> Bikeshed away! :)
>>
>> Jan
>> --
>>
>>
>


--=20
NS

--f46d0447a291a553b604d9f533ab--