You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Wendall Cada <we...@apache.org> on 2013/04/02 01:40:02 UTC
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
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).
> 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
> --
>
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Posted by Wendall Cada <we...@apache.org>.
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 <we...@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 <we...@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
>>>>> --
>>>>>
>>>>>
>>>>>
>
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Posted by Noah Slater <ns...@apache.org>.
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 <we...@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 <we...@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
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Posted by Wendall Cada <we...@apache.org>.
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 <we...@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
>>> --
>>>
>>>
>
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Posted by Noah Slater <ns...@apache.org>.
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 <we...@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
>> --
>>
>>
>
--
NS