On Mar 30, 2013, at 20:44 , Benoit Chesneau <[email protected]> wrote:
> On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt <[email protected]> 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. > > 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. Best Jan -- > > - benoît
