couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: CouchDB LTS branch
Date Fri, 18 Jul 2014 20:15:43 GMT
+1

On 14 Jul 2014, at 13:13 , Robert Samuel Newson <rnewson@apache.org> wrote:

> I like that.
> 
> B.
> 
> On 14 Jul 2014, at 01:45, Tim McNamara <paperless@timmcnamara.co.nz> 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 <rnewson@apache.org> 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 <kxepal@gmail.com> 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
>>>> <rnewson@apache.org> 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 <kxepal@gmail.com> 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?
>>>>>> 
>>>>>> --
>>>>>> ,,,^..^,,,
>>>>> 
>>> 
>>> 
> 


Mime
View raw message