* Uh, _ deprecation_ warnings. ;)
On 31 March 2013 18:06, Noah Slater <[email protected]> wrote: > Actually. Sorry. Let me reconsider that actually. > > I think the important thing I am getting at is that if we can do the API > changes and the BigCouch merge at the same time, then we have two important > releases to do: > > * 1.x line with the depreciation warnings > > * 2.x line with the new stuff > > So, the 1.x line with the depreciation warnings can be done at any point. > In fact, we should probably just commit to doing that in 1.4 right now. > i.e. In three months. > > If the 2.x line is ready to do in three months, let's do it > *simultaneously*. If not, when it's ready. > > Any flaws with this approach? > > > > On 31 March 2013 17:52, Jan Lehnardt <[email protected]> wrote: > >> >> 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 >> >> > > > -- > NS > -- NS
