I recently had to develop an Erlang application targeting Debian "stable". It was humiliating at best. Countless hour were wasted trying to get around bugs in prehistoric packages, or building new (and working) packages from scratch.
I tried to work this out as well. It is indeed using 17.3.x but its hard to nail down which point release, as the Debian changelog doesn't mention when they pull a new upstream version (vs fixing an issue in the package itself)
I figured I would just install the package and use a -v or --version arg to get the exact build version. I cannot find any way to get a patch version out of Erlang. The `OTP_VERSION` file simply says 17.3, and the most I can get from `erl` or `erlc` is "17".
I think this is a massive downside for Linux, and saying "use unstable" just puts the onus on the user to solve it for themselves. Stuff like PHP, MySQL/MariaDB, Postgres and Python isn't part of the OS anywhere else, but it is on Linux. Making tons of third-party userspace software part of the OS distribution causes the distribution of that software to lag behind on Linux. I don't see any reason that what version of Debian you use should lock you into a default version of Erlang, instead of simply letting a user install whatever version of Erlang they need quickly and easily. For all the bleating during the systemd flame war about how Debian and Linux is about choice, it's a very constrained form of choice.
EDIT: Well, that's not true, I see the reason -- Linux isn't an OS so much as it is a family of OSes that are assembled from a lot of independently developed projects and are loosely compatible with each other, so the reason you need a Debian-specific version of Erlang is because Debian isn't quite the same as Arch or Fedora or what have you. I just don't think that it's such a great reason that users should just accept that it'll never get better.
I think you are looking at it wrong. It is not just "use unstable", it is "use unstable if you want to apt-get install stuff".
You can always install the version you want, you just have to compile it, including it's dependencies if needed (using a custom path for libraries).
If you need to do that for multiple machines, build your own packages.
You have a choice how you want to get stuff on your system.
People creating software packages that are in the official repository make it easy for multiple projects to reuse stuff and it works out for most people most of the time.
Looks like 17.3 from the package name. Today it might not be "way" behind, but it will be in a year or two. Or three.
I can see the point of having a "stable" kernel, but these freezes are mostly random. Back in its days, Squeeze shipped with R14A (not B). That's not stable, it's just a random cutoff. It means that whoever did the package did not even know what A and B used to mean in Erlang releases.
This is what backports is all about. More up to date packages from sid, built for the current stable release.
If you're a heavy erlang user you could also consider helping to support the Debian packages for it, I'm sure they'd (Debian erlang team) appreciate any help offered.
Generally I start off with stable, add things via backports if possible, then build my own solution for the primary language runtime and any libraries I'm using.
The idea is to lean on stable for everything else that you don't care as much about, basically.
Live dangerously: deploy on Arch. Then you'll never have to work with outdated anything again ;)
Actually, although I've been using Arch Linux for over two years now (not in production; I'm not brave enough), I've hardly had any issues at all with its rolling updates. The worst was just having to manually delete some Java binaries from /usr/bin when the way it handled Java was updated to allow Java 7 and 8 to exist side by side.
I know a lot of people who use Arch. I myself used Arch for about 10 years. Everyone I talk to has glowing reviews of it, and they've never had any issues.
I stopped using Arch about 3 years ago after my system became unbootable after an update. It was no the first time. In the past, I would be fine reading update notes and fixing the issue. But since I started troubleshooting servers at work, I have zero patience for doing it at home.
One other annoyance that comes with rolling releases is that you should update more often, to avoid making bigger (sometimes conflicting) changes to your system. You end up reading release notes more often. I could turn on automatic updates, but I've been bitten by that in the past.
Arch also encouraged me to tinker, and I was much more likely to make breaking changes to my system than I am now just running Ubuntu. If I had the time/energy to try out new distros at home, I would probably try Nix or something similar, that emphasizes rollback capability.
The thing with "rolling-releases" is that updates will bite you in the ass exactly then when you have absolutely no time to deal with them.
So even if the system boots, it doesn't mean anything because booting a system is only one out of 100+ use cases that you will never be able (or willing) to test after each pacman -Syu..
Since 18 was released in the past 30 days you'd need to wait a little for debian/ubuntu/etc maintainers to work it out for (eventually) production environments.
Here is a quick howto for down and dirty backporting:
Then you have 18.0.something source packages and installable binaries for whatever debian release you have. Check the build-depends in debian/control or try apt-get build-dep erlang first.
If you want a newer release and its just a minor change like 18.0.2 surely is... then just download their current source file and rename it like the orig file you downloaded from debian. Or go update the entry in debian/changelog to properly represent it. (dch -v 1:18.0.2-1~olgeni+1 -m)
It only takes a few minutes in prep work and a couple commands to complete. Most of the time is spent waiting for something like erlang itself to compile before it pops out installable binaries for whatever version of debian you're on. Plus now you have 1-for-1 installable runtime for all your other nodes or environments without any work.
Never again.