I like that. B.
On 14 Jul 2014, at 01:45, Tim McNamara <[email protected]> wrote: > 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? >>>>> >>>>> -- >>>>> ,,,^..^,,, >>>> >> >>
