Standard release schedule for Erlang/OTP. Same thing with R13A, and so on backward (except that the A releases have not previously been available outside of Ericsson (and had the name P rather than A)).
The R14B release is the real release of R14. Will then be incremented with R14B-1 etc.
I would recommend Erlang developers to use the B releases in development, but wait for the B-1 release before upgrading production servers.
Actually, what I find most interesting is that looking at their tracker stats:
http://www.erlang.org/stats/torrent.html
reveals surprisingly small download counts. It isn't clear when the download counts were last reset (or if this is accurate at all?), but so far, only 13 people have completed a download of this latest build via the torrent, and at most a few hundred of earlier versions. Interesting way to estimate the size of the "active" Erlang community?
This doesn't hold account of people installing it through packages or compiling from the github repositories or downloading the flat file without a torrent.
Understood. I suspect flat file is #1 (although it's a big file and the erlang.org server isn't on the world's fastest pipe). I doubt too many "active users" use distro packages because of how out of date they often are. But to me, just for an order of magnitude estimate, it suggests an active Erlang community of perhaps a few thousand users. Just helps me put a number on it when I had no reference previously. You probably have your own estimates based on your traffic stats... and thanks for your Learn You Some Erlang tutorial: http://learnyousomeerlang.com/ !
Yeah, Learn You Some Erlang gets an average of 4800 unique visitors (or 41500 page views) a month according to awstats.
There are about 100 (mostly idling) users in the #erlang channel on freenode and a few hundreds on the mailing lists. There are 1,800 subscribers to r/erlang on reddit. You have 719 watchers of the Erlang/OTP project just on github. Trapexit's project tracker has a bit more than 1450 projects (http://projects.trapexit.org/web/) there.
Note that it's been a few versions since Ubuntu started shipping with a minimal version of Erlang to allow CouchDB to be used there, so the repository stats likely show a whole damn lot of users, so it'd be hard to count how many developers you have precisely.
A few thousand developers might be a good estimate, although those would only be the vocal, active ones.
Companies with telecom products are generally conservative about switching Erlang versions. Most of Corelatus' production systems run R11B-5. Quite a few still run R9C-2. There's no compelling reason to upgrade them, there are thousands of those systems in dozens of countries and most run billing systems. They typically run for years at a time and only get upgraded in conjunction with a larger system upgrade.
It's not like you sit there typical 'apt-get update' a couple of times a day to see if there's anything new you might want...
On the other hand, people who are new to the language generally like to use the very latest because it contains the most features. E.g. later versions have increasingly good SMP support, which may be important if you're working on something which has to scale across many cores, but it's completely irrelevant to me because our hardware only runs Erlang on one core.
My suggestion for a starting point: if you're just developing, follow the R14 sequence, i.e. every time a new one gets release, download it, compile and install from source. If you're ready to deploy now, use R13B04 and let others find the bugs in R14.
Potential biases: I work at Corelatus. I've worked for Ericsson. I maintain the Erlang FAQ.
Only that packages ending with 'A' are supposed not to be production ready. Every 'B' version is advertised as good for production.
There should be backwards compatibility between two major releases, but not more. You could likely go from R14B to R15B, but optimizations and bug fixes usually make it worth it to upgrade in certain circumstances and setups.
I can't help you with Ubuntu, though. That's the responsibility or choice of the person in charge of the packages.
This is where Node.js and Clojure fanboys should learn from. First ones, about what is real concurrency, second ones - what is a functional programming (as opposed to code imperative stuff in a funny lisp-like systax). ^_^
I don't know about why so many, but my own comments are based on a some sort of a cognitive dissonance between what I read in the related mailing lists and in classic CS books like SCIP or what I've learnt from a Berkeley's courses.
"This release is mainly a stabilization of the R14A release (which was a beta) but there are some new functionality also."