+1 to all of this.
Regards, Robert Newson > On 27 Feb 2026, at 09:00, Jan Lehnardt <[email protected]> wrote: > > After our abortive attempt to port CouchDB to FoundationDB a few years ago, we > now have a number of new features available or landing soon that in summary > would make a good cut-off point for calling the result CouchDB 4.0. > > The narrative frame that came to my mind is that this set of features > “(finally) > resolves the major issues people might have with CouchDB”. Not saying everyone > runs into these issues, but once you do, the consequences are rather annoying > and it would be great if normal CouchDB use didn’t lead there in the > first place. > > ## Features > > In particular, I am thinking of these flagship features: > > - tombstone deletion via the new time-seq (landed in `main`) > > - reducing intra-cluster conflicts via selecting a primary node for writes > (https://github.com/apache/couchdb/pull/5371) > > - the need to run database-per-user as solved by per-doc-access-control > (https://github.com/apache/couchdb/pull/5842) > > - faster validated writes with declarative VDU > (https://github.com/apache/couchdb/pull/5839) > > - reduced IOPS- and data storage needs with generational compaction > (https://github.com/apache/couchdb/pull/5583) > > - modernised Search allows to run on modern JVMs, and also Nouveau (3.5.x and > `main` > respectively) > > - truly non-blocking writes with parallel preads (3.5.x) > > [these just of the top of my head, if you find other features that support the > narrative, please do respond :)] > > ## New Defaults > > In addition, during the development of the 3.x.x series, we have started > adding > new sensible configuration settings that we kept OFF by default for backwards > compatibility, that we now can turn ON by default. With the option of folks > switching the config back if the need that compatibility, but opting new users > into sensible defaults. I don’t have a list of this handy, but I plan to set > up > a milestone on GitHub where we can collect these. > > ## Deprecations and Removals > > Similarly, we can finally remove things we have marked deprecated for a good > while now (show, list e.g.) and we have a chance to mark other things as > deprecated in future 3.x releases that we then remove for 4.0. > > The big one here is supporting SpiderMonkey as the JS engine for CouchDB. We > now > have a viable contender with QuickJS that is operationally superior and we > have > a lengthy transition period for people to make the move. And for most users, > it’s a seamless transition and only very few folks will have to rebuild their > indexes, which can happen slowly and in the background. > > SpiderMonkey is causing considerable issues when packaging CouchDB with RHEL10 > packages already having switched to QuickJS-only because of SM-unavailability. > > In conclusion, it is time to remove support for SpiderMonkey. > > ## Timeline and Releases > > Again, I’ll also set this up in GitHub so we can collaborate on tracking > progress, but here’s my rough suggestion for what a release timeline could > look > like: > > - 3.6.0 ships what is currently on `main`, is blocked by a per-db config API > (https://github.com/apache/couchdb/issues/5685). Also deprecates SpiderMonkey. > > For each of these in-progress features, I am envisioning a point release, but > as some might land at the same time, we don’t have to artificially split them > up into separate releases, but these are: > > - reduce intra-cluster conflicts > - per-doc-access > - generational compaction > - mango VDU + advanced selector features > > These could map neatly onto 3.7, 3.8, 3.9 and 3.10, but as I said, we might > coalesce some of these. > > 4.0.0 then: > > - removes SpiderMonkey, makes QuickJS default JS engine > - enables auto-tombstone removal by default > - enables generational compaction by default > - swaps TBD configs to ON by default > > This should give everyone ample time to make a migration and make 4.0.0 as > safe > to upgrade to as our previous major versions past 2.0.0, as we do not > introduce > any incompatibilities that could not be adjusted to leading up to the release. > > — > > What do you all think of this plan? > > Best > Jan > —
