On Mar 31, 2013, at 20:10 , Noah Slater <[email protected]> wrote: > If the BigCouch merge is ready for the next feature release date, then I > would probably need a little more convincing if the proposal was to delay > it by 3 months so that we could cut 2.0.0 to make a point about version > numbers. If BigCouch is not ready by the next feature release date, then I > have no problems whatsoever in shipping a 2.0.0 with API-only changes. > Reasonable?
yup, and agreed, i just didn’t want to put any time pressure on the BigCouch merge process. Jan -- > > > On 31 March 2013 19:08, Jan Lehnardt <[email protected]> wrote: > >> >> 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 >> >> > > > -- > NS
