[DISCUSS] Erlang version update process for convenience binaries

[Adam Kocoloski <ko...@apache.org>]

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.

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.

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.

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?

Adam

Re: [DISCUSS] Erlang version update process for convenience binaries

[Adam Kocoloski <ko...@apache.org>]

Thanks for the input Dave! My only reservation about Erlang 24 is that Bob Newson tells me Clouseau needs some updates to handle the new process aliases. I’d be fine to have packages for the next CouchDB release target Erlang 24, but I’m a little worried about breaking users if we bumped the current version today.

I moved all the CI images for 3.x to Erlang 23, and I submitted a PR in couchdb-pkg to bump that as a default. I’ve generated all new packages for the Linux distros for 3.2.1 with incremented package release versions and can upload those to Artifactory once that PR is merged. If we can validate Erlang 24 with search indexes I’d be happy to spin through another round of packaging.

I haven’t touched any older CouchDB releases yet and don’t have any firm plans to do so.

Adam

> On Jan 27, 2022, at 4:00 AM, Dave Cottlehuber <dc...@skunkwerks.at> wrote:
> 
> 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

Re: [DISCUSS] Erlang version update process for convenience binaries

[Dave Cottlehuber <dc...@skunkwerks.at>]

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