On Wed, 12 Jan 2022, at 18:39, Adam Kocoloski wrote: > Hi, > > Our convenience binaries are using Erlang 20, and we are now seeing > users file bug reports for issues that have been fixed by the Erlang > team more than 3 years ago :( In recent years the Erlang/OTP team has > accelerated their release cycles, and we are now _way_ behind the > current Erlang 24.2 release.
Overall I agree we should fix this. Since switching ~ 2-3 years ago to tracking very latest OTP releases, I've reported a couple of severe core-dumping bugs upstream and they have been dealt with promptly. Even on my admittedly obscure setup, on the bleeding pre-release edge of OTP. I don't think we take major risks from tracking at N-1 (i.e. OTP 23 & 24) in general. I think most of the wider BEAM community tracks latest OTP since the JIT anyway. It is absolutely a major change, and it's worth us switching to that by default everywhere if we can. > I took a peek at the RabbitMQ official image history, and it seems the > Docker folks are rebuilding and publishing images for supported > RabbitMQ versions to use the newest Erlang/OTP on the day it’s > released. That’s aggressive! But I am thinking that we might want to > head toward that general direction and give users a CouchDB install > that packages the current Erlang version by default. On FreeBSD, we do pretty much the same, not *quite* as fast as those mad hatter bunnies though. OTP updates land in FreeBSD typically less than a fortnight after publication, and 2-5 days later that is in our CouchDB packages too. I have kept a close eye out on the errata patches (tag releases, every few weeks), and gut feel says it's a win to keep up to date. FreeBSD is shipping latest OTP24 for CouchDB, and nobody has thrown anything at me yet. > One question I had in my head was whether to publish packages / images > for multiple major Erlang versions, but it doesn’t seem to be a common > practice. No. The number of people who are shipping CouchDB+custom OTP code must be vanishingly small, and those people should be capable of raising questions here for assistance. It also makes more work for packagers. > I also wondered whether to pin a given CouchDB release to an Erlang > release series, e.g. CouchDB 3.2.0 packages are built against the > latest Erlang 20 patch release, while 3.2.1 could jump to Erlang 24. I > think the cognitive load for debugging support tickets might be lower > in that approach. What do you think? I can't speak for elsewhere, but generally sticking to latest OTP is the least work in general from my perspective. A+ Dave
