I recommend dealing with the API deprecation socially, rather than technically. Client developers will read release notes, they're not going to check HTTP headers.
Rather than a custom header, which will impose a non-zero cost on every request, let's just have up-front documentation and communication beforehand. In 2.0, use of 410 Gone seems sensible, though. Tim McNamara @timClicks <http://twitter.com/timClicks> | timmcnamara.co.nz <http://timmcnamara.co.nz/> On 14 July 2014 08:53, Robert Samuel Newson <[email protected]> wrote: > > 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. > > B. > > On 13 Jul 2014, at 14:03, Alexander Shorin <[email protected]> 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 > > <[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? > >>> > >>> -- > >>> ,,,^..^,,, > >> > >
