>From an organisational point of view, it seems much more simple to me to do this simultaneous "deprecate bits in the 1.x line while starting a new 2.x line" thing. The bit I don't know is whether this makes sense from a technical point of view. Your plan, for instance, spaces out the API changes and the BigCouch change. If those can be done in a single release, then I reckon we can do this *whole thing* in a single dual release. Booya!
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
