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?
On 31 March 2013 19:08, Jan Lehnardt <j...@apache.org> wrote: > > On Mar 31, 2013, at 20:06 , Noah Slater <nsla...@apache.org> 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 <j...@apache.org> wrote: > > > >> > >> On Mar 31, 2013, at 19:06 , Noah Slater <nsla...@apache.org> 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 <j...@apache.org> wrote: > >>> > >>>> > >>>> On Mar 31, 2013, at 18:41 , Noah Slater <nsla...@apache.org> 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 <nsla...@apache.org> 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 <j...@apache.org> 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
