The Makefile in the project pulls a copy of Go v1.1.2 into the local tree, builds, and uses that to build websockets:
# Self contained Go build file that will download and install (locally) the correct
# version of Go, and build our programs. Go does not need to be installed on the
# system (and if it already is, it will be ignored).
> 2. To ensure that anyone who builds and releases it always uses the exact same version of Go.
Please don't do this! It's attempting to solve a problem that doesn't exist.
As I mentioned above, Go does not have compatibility issues with different version of the compiler. This is a huge strength of Go, and spreading the idea that using the same version of Go is somehow beneficial creates misunderstanding for new developers.
I challenge anyone to find an example of Go 1.x code in which using the most recent version of the compiler will build an incorrect binary. Seriously, if you find one, please let me (or better yet, the Go mailing list) know, because the Go team has made a dedicated effort to make sure that this doesn't happen. (Such cases exist, but I am fairly certain without even looking that this program doesn't run into any, whereas it's clear (below) that the Makefile for this project doesn't handle cases that the standard build tools do.)
I didn't understand this when I started using Go over a year ago - at the time, I also used Makefiles over Go's built-in build tools, and did a number of other non-idiomatic things surrounding the build process. More experienced Go programmers told me I was wrong, and I didn't listen at first. In the end, I finally realized that they were right: it added complexity for literally zero value. Please don't make the same mistakes that I did.
Sure, but that's a very complex solution to a very simple problem.
While using older versions of Go is not recommended, it's not going to cause you any problems unless you're relying on (e.g.) 1.2-specific syntax like the three-argument slice syntax introduced in 1.2. If you are doing that, then older versions of the compiler will fail to parse the code, which would hopefully motivate the developer to upgrade their system-wide Go installation[0]. That way, they still only have one version of the compiler installed, and it will work for all programs they need to compile.
The only people who need to have multiple different versions of the gc compiler installed on their system are people who know what they're doing and handle this themselves manually (ie, the core contributors to Go).
One of the explicit design goals of Go is to simplify the build process. A side-effect of this is that the build process and best practices are different for Go than for most other languages.
I appreciate the effort that you've put into trying to make this easy to deploy, but using Makefiles and local versions of the compiler in this way is generally bad practice for experienced Go programmers, and encourages bad habits for inexperienced Go programmers.
[0] Ubuntu's repositories are hilariously behind the times on this. That's a separate matter of discussion, but it's why it's not encouraged to install Go through the main Ubuntu repositories.
I noticed that the Makefile downloads Go over plain http and runs it immediately. It is a security risk to run software without proper verification of its origin.
