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

Reply via email to