+1 The only thought that comes to mind is that it might be useful to differ in some of our error messages between versions. AFAIK, there's nothing from 19.x that currently would prevent someone from using it. We just don't have the resources to cover all of the tests and packaging for it. Which is different than some than the black-listed 20.x versions which have known bugs that break things.
So, basically having something like Allow/Warn/Block classifications rather than an opaque "This version is not supported" error message? On Thu, Dec 12, 2019 at 2:34 PM Dave Cottlehuber <d...@skunkwerks.at> wrote: > > On Thu, 12 Dec 2019, at 01:35, Joan Touzet wrote: > > Hello everyone, > > > > I'm working this week with Paul Davis on our new Jenkins CI > > infrastructure, which is coming along nicely. One of the changes I'm > > planning to make is that our PR tests will run against only 3 versions > > of Erlang: > > > > 1. The oldest we support (right now, 19.3.6.latest) > > 2. The version we currently ship with our binary distros & Docker > > (right now, 20.3.8.latest) > > 3. The very latest version we support (right now, 22.2) > > > > In preparing the containers for CI testing, it's turning out to be very > > difficult to build Erlang 19.* anymore on modern Linuxes. This is > > because they ship with OpenSSL 1.1+, and 19.* cannot build against > > anything newer than OpenSSL 1.0. > > > > I can jump through a huge number of hoops for this...or we can just drop > > Erlang 19 support for CouchDB 3.0 and require Erlang 20. (Note we > > blacklist a number of versions of Erlang 20.) I would then replace > > 19.3.6.latest with 20.3.8.11 [1]. > > +1 > > FWIW RabbitMQ has done the same (21 & 22 only soon), and in FreeBSD > we drop <19 from January, and I expect to be more aggressive on that > in future, in line with what the OTP team have stated. > > I would consider going with 21+ only and be done with this. > > A+ > Dave
