On Mar 31, 2013, at 20:06 , Noah Slater <[email protected]> wrote: > I understand what you are saying, and I agree with it. > > But the API only release seems unnecessary to me. If the version numbers > are not important (and they are not) then let's just treat them that way > and ship BigCouch in 2.0.0. Actually going out of our way to make a bunch > of (otherwise unneeded) API-only changes so that we can cut an (otherwise > unneeded) feature release, just so that we can say "see! the version > numbers are not important!" seems a little... over the top to me. Almost > like we'd be doing so far out of our way to convince the world that we > don't think this is a big deal... That we turn it into a big deal again. > Heh. Do you see what I'm saying? (Hard to explain!)
I see what you mean, but I still think it sets the right tone. If the 2.0.0 release announcement is as brief as the 1.2.2, I’d be happy :) Jan -- > > > > > On 31 March 2013 18:44, Jan Lehnardt <[email protected]> wrote: > >> >> On Mar 31, 2013, at 19: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? >> >> I didn’t reveal one of my motivations: I’d like to get us as far away >> from “big” releases as possible. In an ideal world, the difference >> between a 1.9.0 and a 2.0.0 is a small backwards incompatible change. >> >> I don’t want 2.0.0 to be blown up as this big release. Or abuse the >> version number for marketing “CouchDB 2.0, now with more pizzazz!”. >> Or where we start cramming in more and more BC breaks because this >> is finally the release where we can clean it all up (c.f. Python 3 >> as a cautionary tale about upgrading). >> >> 2.0.0 is just another small step in the increment game we are now playing >> and is unrelated to any actual big changes we are making, like the >> BigCouch merge. >> >> Hence my suggestion to make 2.0.0 just forward compatible with >> BigCouch. Then BigCouch can land any time later. >> >> So: >> >> In 90 days: >> - 1.4.0 with deprecation warnings. >> - 2.0.0 with the changed API. >> >> In 120 days (or later if required by getting the code ready): >> - 3.0.0 with BigCouch. >> >> Give that, I’d suggest we branch 1.4.x and 2.0.x soon-ish, so >> we can get master ready to be 3.0.0 so that we have loads of >> time to refine the BigCouch merge. >> >> Jan >> -- >> >> >> >> >>> >>> >>> >>> 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
