couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Date Sun, 31 Mar 2013 16:52:29 GMT

On Mar 31, 2013, at 18:41 , Noah Slater <nslater@apache.org> wrote:

> * There's _no_ reason, that I can see, that this deprecation has _to
> happen_ 3 months prior.

Yeah, that works too, it is the same procedure, just compressed some
more. I don’t think we intended anything special with an artificial
three month delay. Good catch!

Cheers
Jan
--


> 
> 
> On 31 March 2013 17:40, Noah Slater <nslater@apache.org> wrote:
> 
>> I'm probably missing something here, but why can't we land BigCouch in a
>> single dual-release?
>> 
>> Timeline:
>> 
>>    * BigCouch lands on master
>>        * No date — it happens when it happens
>>    * We simultaneously release 2.0.0 and 1.X.0
>>        * This happens at the next available regular release date
>>        * 2.0.0 is cut from master (with API changes and BigCouch)
>>        * 1.X.0 is has X-CouchDB-Deprecated headers added
>> 
>> This assumes the API changes and BigCouch can happen in a single release.
>> 
>> The upgrade path is from 1.X.0 to 2.0.0. We simultaneously deprecate bits
>> of the API while releasing a new version of it in BigCouch. There's on
>> reason, that I can see, that this deprecation has 3 months prior. People
>> can then just keep using the 1.X line until they are comfortable to move
>> over.
>> 
>> 
>> 
>> 
>> On 30 March 2013 19:29, Jan Lehnardt <jan@apache.org> 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
>>> --
>>> 
>>> 
>> 
>> 
>> --
>> NS
>> 
> 
> 
> 
> -- 
> NS


Mime
View raw message