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 <[email protected]> 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 <[email protected]> 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. >> https://github.com/chewbranca/test_couch_file_migrations >> >> So which CouchDB 1.x release will be LTS and what are our plans/workflow for >> it? >> >> -- >> ,,,^..^,,, >
