Hi all,
*Per the CouchDB bylaws, this is a concrete proposal that will default
to lazy consensus in 72 hours (2017.07.19 ~21:00).*
As we approach release candidates for v2.1 (see next email), we have one
major decision left to make: whether or not to include the scheduling
replicator in 2.1.
Arguments for inclusion:
* New feature allowing CouchDB to manage more replication jobs at
the same time by switching between them / starting / stopping.
From the documentation:
* Handles failing jobs more gracefully (exponnential backoff).
* Includes a new pair of API endpoints: _scheduler/jobs and
_scheduler/docs with enhanced information and an updated state
machine for replication jobs.
* Shared connection pool improves network resource usage and
performance, especially with large numbers of connections to
the same source/target.
* Improved request rate limit handling.
* Improved recovery from long but temporary network failures.
* Better handling of filtered replications.
* Feature includes its own tests, which all pass.
* Feature is fully documented.
* Cherry-picking out the scheduling replicator commits from the
~190 commits since then (all bugfixes and minor improvements) is
labour intensive for the release team, and possibly error prone.
Arguments against inclusion:
* It has been ~9 months since the 2.0 release. Many bugs have been
found and fixed.
* A new release without the scheduling replicator would provide
risk mitigation for users who need those bug fixes but are risk-
averse to new features.
* Scheduling replicator has not seen much real-world testing. Bugs
may surface in a 2.1 release that could destabilise existing
installs being upgraded.
I've thought a lot about this issue, and would like to propose that we
release 2.1 *with* the scheduling replicator included. My reasoning is
that the benefits outweigh the potential downsides. If necessary, we
can release a 2.1.1 in the following weeks with urgent bug fixes to
the scheduling replicator if necessary.
Another alternative would be to ~simultaneously release a 2.1 from just
before the scheduling replicator landed (~190 commits ago), then a 2.2
from the HEAD of the master branch with all the subsequent fixes. 2.1
would be missing these more recent fixes, but it would again avoid the
massive cherry-picking operation necessary to port all of them to the
2.1 branch without the scheduling replicator. I'm -0 on this because
of the confusion it might create with release announcements, but
wouldn't block if that was the desired path forward.
Developers, please make your voices heard! :)
-Joan
