On Mar 31, 2013, at 18:41 , Noah Slater <[email protected]> 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 <[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
