* There's _no_ reason, that I can see, that this deprecation has _to happen_ 3 months prior.
On 31 March 2013 17:40, Noah Slater <[email protected]> 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 <[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. >> >> 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
