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:06:52 GMT
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?



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