Hi devs,

CouchDB 2.0 obliviously breaks the backward compatibility. I think
this is good moment to review our current issues which are also
requires to break the BC.

For instance, spidermonkey version. We cannot use recent SM versions
since anonymous functions are gone after 1.8.5 release and that moment
breaks all the existed design functions.
https://issues.apache.org/jira/browse/COUCHDB-1397

Another one is about changing Revision (_rev) into something more less
misleading:
https://issues.apache.org/jira/browse/COUCHDB-1399
(or we eventually have to implement version control module for CouchDB one day)

Our view server is compiles functions on each view index update
instead of reusing inner cache. This is because of out-dated protocol:
others design function are works differently from views. While it's
good to change and improve query server protocol completely, this task
requires more time to be done. We should have a least plan B to do
small steps in good direction.

API consistency:
- timeout and heartbeat params for /_db_updates works in different way
then the same parameters for changes feed;
- we need to find the way to pass open_revs in POST body instead of
tweaking max URL param;
- we have /db/_revs_diff and /db/_revs_missing endpoints which are
doing the same job. Well, the latter is only used for pre-1.1 CouchDB
replicator.
- /db/doc accepts conflicts, deleted_conflicts and revs params. In the
same time we provides meta one which includes each of specified.
- make eventsource feed to follow the specification format more better
then it does now
- MVCC for /db/_security and allow atomic changes for admins/members only

That's only a few of the moments which are on my mind now, I believe
there are a lot of others. While each of them shifts 2.0 release more
in time, we shouldn't miss the moment when we can break the backward
compatibility for free to improve CouchDB and cleanup legacy bits.

I propose to collect all the BC stuff on JIRA. After that we could
decide what we could change, what we will and what we'll not (because
of no reasons for or lack of time).

--
,,,^..^,,,

Reply via email to