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 Wed, 10 Apr 2013 00:54:34 GMT
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
>>>> --
>>>>
>>>>
>>>>
>>
>


-- 
NS

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