On 2021-01-22 4:37 p.m., Robert Newson wrote:
Iteresting. I’m actually surprised at the inversion here (that CouchDB is
dependent on IBM to confirm CouchDB’s stability). I’ve always agonised over
even the perception that IBM/Cloudant is calling the shots. I appreciate the
reassurance
+1 on dropping Erlang 19
It's been a best-effort support for it anyway, if I remember the last
discussion about it correctly.
I looked at the failure in the CI and it looks like we're failing on
the ceil/1 function in couch_emsort.erl. We already shipped 3.1.1 with
that change and the commit is
Iteresting. I’m actually surprised at the inversion here (that CouchDB is
dependent on IBM to confirm CouchDB’s stability). I’ve always agonised over
even the perception that IBM/Cloudant is calling the shots. I appreciate the
reassurance that running at scale provides, of course, I just
On 22/01/2021 15:48, Robert Newson wrote:
> I’m +1 on dropping Erlang 19 support. Erlang is now on major release 23.
No problem here.
> I’d further advocate a general policy of supporting only the most recent 2 or
> 3 major releases of Erlang/OTP.
>
> The main (I think only?) reason to keep
I’m +1 on dropping Erlang 19 support. Erlang is now on major release 23.
I’d further advocate a general policy of supporting only the most recent 2 or 3
major releases of Erlang/OTP.
The main (I think only?) reason to keep compatibility so far back is because of
the versions supported by some
Hi All,
CI for https://github.com/apache/couchdb-config appears to be broken.
I wanted to fix it in
https://github.com/apache/couchdb-config/pull/34/files , but I'm
getting issues with erlang 19. Are we okay with dropping 19 support
there?
On a different note: are we okay with dropping erlang 19
Hi,
I noticed the test suite for 4.0 sets an application environment variable
{fabric, [{eunit_run, true}]} that results in erlfdb starting a new fdbserver
instead of using the one defined in the fdb.cluster file that it would use
otherwise. I think that’s a reasonable default especially given
