Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of wendallc@83864.com designates
 209.85.210.45 as permitted sender)
Sender: Wendall Cada <wendallc@83864.com>
Message-ID: <5164BE86.7090705@apache.org>
Date: Tue, 09 Apr 2013 18:21:10 -0700
From: Wendall Cada <wendallc@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: dev@couchdb.apache.org
Subject: Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
References: <6760C936-9099-4031-9844-650F46A18341@apache.org>
 <515A1AD2.1060808@apache.org>
 <CAPaJBx6XbYSGsbitoexcYEyUBxJW+v48EQhBNanryS584n3UjQ@mail.gmail.com>
 <5164AF86.7030701@apache.org>
 <CAPaJBx5=04-ze=kEHQ1_+btSCPZyd3BMtNXAqrGQ5gqfparXYg@mail.gmail.com>
In-Reply-To: 
 <CAPaJBx5=04-ze=kEHQ1_+btSCPZyd3BMtNXAqrGQ5gqfparXYg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Ok, cleared up. Thanks Noah.

Wendall
On 04/09/2013 05:54 PM, Noah Slater wrote:
> Agreed that major dependency changes might constitute a major number
> increment.
>
> See this part of the doc I linked:
>
>> Each feature release will be supported for 12 months.
>> Therefor, at any one particular time, there should be four supported
> feature releases.
>
> Does this seem reasonable to you?
>
>
> On 10 April 2013 01:17, Wendall Cada <wendallc@apache.org> wrote:
>
>> Thanks Noah, this certainly addresses the semantic versioning issues, and
>> support windows for feature releases, however, I'm still unclear about some
>> other points.
>>
>> How long do major branches get support? Are we forever stuck porting
>> security fixes to 1.0.x, or does this get retired at some point? I can see
>> a path moving forward, but what is unclear is how long we will support
>> older branches. What policy internally is in place that determines what
>> fixes get back ported, and what just stays broken?
>>
>> In my day job, where we use CouchDB heavily, I've been able to update our
>> application frameworks to the latest CouchDB release with almost reckless
>> abandon. The api has changed very little (which is a wonderful thing),
>> allowing for mostly painless upgrading. Personally, I find that
>> requirements changing and updating at a faster pace than distributions is
>> more often the limiting factor. This should be reflected in the semantic
>> versioning as well. For example, say we decide that 1.3.1 needs
>> spidermonkey 17, and spidermonkey 1.7 support is dropped, this isn't a
>> patch, and could very well be considered a breaking change. Pretty much any
>> major external requirement update can pose a potentially breaking change
>> for packagers where they may be unable to update to the latest version
>> based on factors outside of their direct control.
>>
>> Wendall
>>
>>
>> On 04/09/2013 03:37 PM, Noah Slater wrote:
>>
>>> I think our roadmap process answers this:
>>>
>>> http://wiki.apache.org/**couchdb/Roadmap_Process<http://wiki.apache.org/couchdb/Roadmap_Process>
>>>
>>> Let me know if you think we need something more than this...
>>>
>>>
>>> On 2 April 2013 00:40, Wendall Cada <wendallc@apache.org> wrote:
>>>
>>>   One item missing from this is support of existing versions. I'm not sure
>>>> if a timeline exists for this, but it should be well understood what the
>>>> support window will look like for old versions.
>>>>
>>>> Wendall
>>>>
>>>>
>>>> On 03/30/2013 12:29 PM, Jan Lehnardt 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<https://issues.apache.org/**jira/browse/COUCHDB-1756>
>>>>> <https**://issues.apache.org/jira/**browse/COUCHDB-1756<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
>>>>> --
>>>>>
>>>>>
>>>>>
>