couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: CouchDB LTS branch
Date Sun, 13 Jul 2014 20:53:56 GMT

I’m more than a little skeptical that anyone would notice but I’d like to hear from others.
Perhaps if we couple that with a loud announcement at release time, with instructions on what
to look for, it would work out.


On 13 Jul 2014, at 14:03, Alexander Shorin <> wrote:

> IIRC there was suggestion about using custom header like
> X-Couch-Deprecated: version-when-deprecated. This shouldn't break any
> client library, but will give them a change to handle it and show the
> warning. + Deprecation tags in our docs. For 2.0 release we could
> respond on deprecated endpoints with 410 Gone instead of 404.
> If client library is still active, users will expect that it'll get
> updated to show these warnings and it have some plans for 2.0 support.
> Otherwise we cannot do anything for the libraries which are stale and
> users have to looks for more active and up-to-dated alternatives for
> migration.
> --
> ,,,^..^,,,
> On Sun, Jul 13, 2014 at 4:51 PM, Robert Samuel Newson
> <> wrote:
>> This assumes there is a meaningful way to deprecate API endpoints within couchdb,
and I can’t think of one right now. If the response from couchdb is changed to indicate
deprecation, how will we a) ensure no user or client library is broken and b) expect any user
or client library to notice the warning?
>> B
>> On 13 Jul 2014, at 12:47, Alexander Shorin <> wrote:
>>> Hi devs,
>>> BigCouch had finally landed on master few days ago. Hooray! And thanks
>>> a lot to Robert, Davis, Russell and everyone else who made this great
>>> moment real.
>>> This merge is the very important, but first step for making CouchDB
>>> 2.0 release. A lot of work is still have to be done.
>>> However, in the same moment we need to create the last CouchDB 1.x
>>> series release - the LTS release which have to reach the following
>>> goals:
>>> 1) Explicitly deprecate all the API and stuff which will not pass 2.0
>>> borderline.
>>> 2) Provide guidelines, helpers and any other bits which will make
>>> migration to 2.0 (or 2.x) more soft, easy and simple.
>>> Obliviously, that this LTS release couldn't be done within standard
>>> release time frame since it's heavily depended from work on 2.0: need
>>> to at least figure out which API endpoints are gone, missed or need to
>>> be reworked.
>>> Also Russell found some migration issues with database format which
>>> requires it change at least one to simplify the process.
>>> So which CouchDB 1.x release will be LTS and what are our plans/workflow for
>>> --
>>> ,,,^..^,,,

View raw message