ll.
Rich
From: "Dave Cottlehuber"
To: dev@couchdb.apache.org
Date: 07/04/2021 22:17
Subject:[EXTERNAL] Re: [DISCUSS] API versioning redux
On Fri, 2 Apr 2021, at 21:07, Ilya Khlopotov wrote:
> Nice list of questions. Couple more from me:
>
> # global vs per endpoin
On Fri, 2 Apr 2021, at 21:07, Ilya Khlopotov wrote:
> Nice list of questions. Couple more from me:
>
> # global vs per endpoint?
>
> If we decide for API per endpoint we could different mechanisms to get
> list of supported versions:
> {
> "couchdb": "Welcome",
> "uuid":
I think that's a good compromise if we want to bring more users along
from 3.x to 4.x.
In respect to existing users I can see there being at least 4
different categories:
1. Users who know about the snapshotting behavior of 1.x-3.x, and
their applications rely on it for correctness.
2. Users who
Nice list of questions. Couple more from me:
# global vs per endpoint?
If we decide for API per endpoint we could different mechanisms to get list of
supported versions:
- new /_api endpoint which would return list of versions for each endpoint
```
{
"/{db}/{docid}": ["4", "55",
Proposed. Mix and match:
- Any expected behaviors dropped or changed from pre-existing API
versions are available only when API v4 is specified.
- Any existing behaviors, unchanged in couchdb 4, work the same whether
API v4 is specified, or not
- Any new endpoints created in
Thanks for bubbling this thread back up to the top Donat.
I think a “cleaner slate” v4 API has a lot going for it, but if we go that
route without also supporting the v3 API at the same time we’ll be sunk. Python
succeeded in spite of the 2->3 transition, but it was a long and painful road
as
On 2021-03-30 2:35 p.m., Bessenyei Balázs Donát wrote:
>> It'd be like a Python 2 -> 3 transition
>
> I think the simile is spot on.
> But that shouldn't be a problem, it's more like evolution.
>
>> your user base plummet
>
> Looking at [1] and for lack of a better idea for reference [2],
> It'd be like a Python 2 -> 3 transition
I think the simile is spot on.
But that shouldn't be a problem, it's more like evolution.
> your user base plummet
Looking at [1] and for lack of a better idea for reference [2], the
user base issues are not obvious to me.
Having said that, I'm okay
On 30/03/2021 12:57, Bessenyei Balázs Donát wrote:
> If we are bumping major anyways, can we just go "clean slate" and
> promise replication compatibility only?
Basically: watch your user base plummet. It'd be like a Python 2 -> 3
transition, or a Perl 5 -> 6 one. It would take years of
If we are bumping major anyways, can we just go "clean slate" and
promise replication compatibility only?
All that while we'd publish a migration guide that explains the
differences and helps users adjust their implementations, but this way
we'd get rid of some potential complexity.
If we do want
On 22/02/2021 20:48, Adam Kocoloski wrote:
> Hi all,
>
> Several times in recent months we’ve had discussions on this list about
> behavior changes in CouchDB 4.0 that boil down to tradeoffs between
>
> a) maintaining compatibility with current CouchDB APIs, and
> b) capitalizing on the
Thank you Adam for bringing back API versioning discussion.
I think we should adopt API versioning. This would allow us to get a number of
benefits:
1. It would allow clients to choose appropriate API based on explicit API
version support returned response from /
2. It would allow us to run
Hi all,
Several times in recent months we’ve had discussions on this list about
behavior changes in CouchDB 4.0 that boil down to tradeoffs between
a) maintaining compatibility with current CouchDB APIs, and
b) capitalizing on the transactional semantics of FoundationDB
An example would be
13 matches
Mail list logo
