Sounds good to me as well, Thank you, -Nick
On Wed, Mar 4, 2026 at 12:52 PM Robert Newson <[email protected]> wrote: > > +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 > > — > >
