couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McNamara <paperl...@timmcnamara.co.nz>
Subject Re: CouchDB LTS branch
Date Mon, 14 Jul 2014 00:45:11 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message