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 <[email protected]> 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 merge >> (https://issues.apache.org/**jira/browse/COUCHDB-1756<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
