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.192.173 as permitted sender)
Sender: Wendall Cada <wendallc@83864.com>
Message-ID: <5164AF86.7030701@apache.org>
Date: Tue, 09 Apr 2013 17:17: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>
In-Reply-To: 
 <CAPaJBx6XbYSGsbitoexcYEyUBxJW+v48EQhBNanryS584n3UjQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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
>
> 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>
>>> ).
>>> 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
>>> --
>>>
>>>
>