+1 On 14 Jul 2014, at 13:13 , Robert Samuel Newson <[email protected]> wrote:
> 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? >>>>>> >>>>>> -- >>>>>> ,,,^..^,,, >>>>> >>> >>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
