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.
Never again.
Never again.
Were you targeting Wheezy?
If you look here https://github.com/erlang/otp/releases you'll see that - even on Jessie - 17.1 is unfortunately way behind.
17.3.4 was released on 4th of November 2014, according to the link you provided.
Jessie "freeze" happened on 5th of November ( https://lists.debian.org/debian-devel-announce/2014/11/msg00... ), so I even wonder that they are shipping that version.
In my opinion that is not "way behind".
If you need bleeding edge you should move to unstable or testing releases, move to a rolling release distribution like Arch or build your own.
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".
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.
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.
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.
That's not something you can put in production.
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.
The idea is to lean on stable for everything else that you don't care as much about, basically.
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.
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..
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.
One wheezy, that would have put you at 17.1 in less than a minute.
The fact that erlang.org does not list minor releases at all probably doesn't help. One can go to erlang.org and think that 18.0 is the latest...
Here is a quick howto for down and dirty backporting:
https://packages.debian.org/sid/erlang
Get the debian, orig, and dsc files:
cmd: "dpkg-source -x erlang<blah>.dsc"
cmd: "cd erlang<blah>"
cmd: "debuild"
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.