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:10:26 GMT
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 <jan@apache.org> wrote:

>
> On Mar 31, 2013, at 20:06 , Noah Slater <nslater@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 <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
>
>


-- 
NS

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