Closed paulo-ferraz-oliveira closed 2 months ago
@wojtekmach, is this a goal? Feel free to close, otherwise. My thinking would be that we could list Erlang/OTP versions from 25.1 and keep a moving window of support range as newer versions come out. Since we have the .txt
it'd be easy to skip (from that list) to build the next release.
Initially I was planning to only support OTP 27+ but you're right that it is more practical to support the last three major releases so starting from OTP 25.
I'll make sure the build script is generating docs chunks prior to OTP 27 too.
I'll also update the workflow_dispatch to only accept OTP 25+ so we don't accidentally build something we don't intend to support (e.g. erlang/otp sent us a webhook with OTP-24.3.4.X), we can of course lift that restriction up down the road.
👍
If you intend on relying on OpenSSL 3.x, 25.1- can't be included in that range, apparently. I remember having issues trying to compile it, but maybe your process works (?)
My prior notes (from OTP release notes):
"
"
I'll make sure the build script is generating docs chunks prior to OTP 27 too.
Perfect. On a macOS runner it's possible you'll have to make sha256sum
available prior to 27.0-rc3; after that shasum
should suffice.
I was thinking about exceptions and how easy it is to maintain them (not easy!) so it's possible to have a "don't build this OTP version on this macOS version" mechanism (e.g. a simple file with a comment (?)). We can deal with it in the future, because the build mechanism will surely have to be tweaked every now and then.
I updated build scripts to build OTP 25+, there are some caveats with it which I've documented in the proposed README: https://github.com/erlef/otp_builds/blob/wm-initial/README.md#list-of-builds.
This version already supported OpenSSL 3.0 fully, so this'd broaden the build range. It'd make for a faster transition in systems like
asdf
, etc. as well as CI that include the latest 3 Erlang/OTP versions.