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? >>> >>> -- >>> ,,,^..^,,, >>
