couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Date Sun, 31 Mar 2013 18:27:47 GMT

On Mar 31, 2013, at 20:10 , Noah Slater <nslater@apache.org> wrote:

> 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?

yup, and agreed, i just didn’t want to put any time pressure on the BigCouch
merge process.

Jan
--




> 
> 
> 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
View raw message