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 17:03:55 GMT
>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 <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

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