Version numbering

From now on, we’re going to be clearer with our version numbering scheme. Historically, we’ve shipped, say, “4.0.0” to the public – internally, there have been a lot of builds on this target branch, all of which get an internal revision number. “4.0.0” as-shipped was in fact 4.0.0.143 internally – that was the first 4.0.0 branch release approved of for stable release.

This release is the first service release on the 4.0.0 branch, numbered 4.0.1.44 – it’ll be officially referred to as “4.0.1” in some places, but isn’t the same as 4.0.1.0, which already released on Linux/Windows a while back, to include an emergency bugfix for those platforms.

That was sorta a screwup really. Using the 4-part version removes the ambiguity, rather than having 44 different “4.0.1”‘s in existence. And we’ll aim to be clearer in future about what is alpha, what is beta, and what is final (and what is a random emergency snapshot).

Alpha Linux packages

Want to see things earlier? We’ve now got the structure in place to provide Linux packages (and source releases) to mirror what we do on Mac. When we upload a prospective package to our Mac customers, we will automatically trigger builds for Linux too. See http://www.mono-project.com/download/alpha/

Beta Linux packages

See above. s/alpha/beta/.

Weekly git Master snapshots

We already have packages in place for every git commit, which parallel-install Mono into /opt. This is different.

Weekly (or, right now, when I manually run the requisite Jenkins job), the latest Mac build of Mono git master from our internal CI system will be copied to a public location just for you, a source tarball generated, and packages built. See here for info on making use of that.directhex@marceline:~$ mono --version
Mono JIT compiler version 4.3.0 (Nightly 4.3.0.21/88d2b9d Thu May 28 10:54:32 UTC 2015)