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