+1, sounds good. Only for the record:
When I heard the name CouchDB 4.0, the first thing that came to mind was FoundationDB as a storage engine. After a brief discussion on Slack [1], we agreed that this should not cause any confusion, as the FoundationDB feature is long past and a version jump to 5.0 would look a bit strange. [1] https://couchdb.slack.com/archives/C01TBE2J197/p1772197000420689 Am Fr., 27. Feb. 2026 um 10:02 Uhr schrieb Jan Lehnardt <[email protected]>: > 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 > —
