couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Date Sun, 31 Mar 2013 18:06:05 GMT

On Mar 30, 2013, at 20:44 , Benoit Chesneau <> wrote:

> On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt <> wrote:
>> Hi all,
>> It is time to think about how to square the upcoming changes to CouchDB and the next
>> Robert Newson and I hashed out this plan:
>> 1. Compile a list of API changes between now and after the BigCouch merge (
>> 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.
> I'm all for the second planning, it's more safe imo.
>> 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.
> I would probably do first the rcouch merge (ie rebar compat) then plug
> bigcouch. Depends on the time we all have. Maybe we could set a
> deadline (say mid-mai) to take the final decision on that?

I assumed we need some coordination, I hope Robert and Paul can chime in
here on what is a good approach.

>> 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.
> I was more busy than expected these last 2 weeks due to a customer
> urgency. Since I need the full patch for the IP clearance I will
> finished it next week. Will do that before thursday, 4th April. I will
> need some help to make sur that I filled the form correctly right
> after.
> So far I think we can ship it for July and the 2.0.0 .
> Bikesheeding away where do you place in the big plan new features like
> websockets, test refactoring and plugin system. More than when do you
> think they should be shipped in minor releases or major?

As long as we keep backwards compatibility, we can ship in minor releases.
That would probably mean, that a new HTTP layer should wait until after
BigCouch (we can still start working on it now) and be part of a BC break,
while plugins and test refactoring should not affect existing users in
a negative way, so they can happen concurrently. We’ll definitely need to
put some thought into all this, I just thought it helps painting the big
strokes first around the more disruptive things we have on the roadmap.


> - benoît

View raw message