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:07:59 GMT
* Uh, _ deprecation_ warnings. ;)


On 31 March 2013 18: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?
>
>
>
> 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