Hi Joan, I think moving the FDB work to master and having a 3.x branch is a good idea. Cheers,
Adam > On Jan 30, 2020, at 5:58 PM, Joan Touzet <woh...@apache.org> wrote: > > Hi everyone, > > We are finally past our blockers for 3.0.0. The beam hang in Erlang 21 and 22 > seems to be worked around by not raising the priority of the couch_server > process to high. An upstream bug has been filed with Erlang to resolve this; > until that get patched and merged, and we blacklist the bad Erlang releases, > we're disabling the priority raise. > > There are only minor documentation, packaging and build changes left to make. > I predict RC1 will be cut next week. > > I intend to fork a 3.0.x branch off of master very soon - possibly > *tomorrow*. If anyone has any reason why this shouldn't happen, please speak > now. > > This means if you want anything to end up in CouchDB 3.0.0, this is the final > call to clean up and merge your PRs ASAP. > > If you have patches that affect CouchDB, this means that patches may have to > be PR'ed *twice*, once for the 3.0.x branch and once for master. > > Remember, once FDB work hits master, we'll be in a situation where patches > may be landing on multiple branches (if they affect both FDB and non-FDB > CouchDB) or may only end up on a 3.* branch. > > Because of this, do we want to fork now as "3.x", and then fork 3.0.x off of > that? Basically, we'd treat 3.x as our new 'master' for merging anything > non-FDB, and open up master for FDB releases. If FDB landing on master isn't > a priority, we can continue with our traditional forking of 3.1.x, 3.2.x, > etc. off of master until FDB is ready to land there. > > -Joan
