couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Date Sun, 31 Mar 2013 18:06:24 GMT
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!)




On 31 March 2013 18:44, Jan Lehnardt <jan@apache.org> wrote:

>
> On Mar 31, 2013, at 19:06 , Noah Slater <nslater@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 <jan@apache.org> wrote:
> >
> >>
> >> On Mar 31, 2013, at 18:41 , Noah Slater <nslater@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 <nslater@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 <jan@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message