I should keep a released version of the Go compiler suite

October 23, 2016

One of my little development habits with Go is that I track the tip of Go development, built my Go toolchain from it, and update frequently. This almost always works (the tip is only broken very rarely) and it means that I get the latest Go compiler improvements and standard library updates. Every so often I can even help out by reporting a problem (well) before it makes it into a general release.

(Building Go from source is pretty simple once you're set up for it and pretty fast, even including all of the default tests. If it took lots of time to rebuild, I would be much less enthused about keeping current.)

But this does have one drawback now that I'm slowly making more of my Go things public, which is that I can get a little bit fuzzy on what version of Go my public things actually require. Not all that many people run the development version, so ideally I'd keep my public stuff compatible with at least the latest released version (and perhaps even older versions if it's easy). But since I only build with Go tip, it's easy for some dependency to sneak in. Or just for me to explicitly use some nice new development in Go tip without thinking about the impact on other people.

The obvious way to avoid this is to routinely test my code against officially released versions of Go. To do this, I obviously need to have sitting around the latest release, or perhaps several releases; right now, that's at least Go 1.7.3 and perhaps some 1.6.x version.

(Sure, it'd be nice if everyone used the latest Go, and building it yourself isn't too hard. But a lot of people only use (pre-)packaged vendor software and right now both Fedora and Ubuntu LTS are still shipping Go 1.6, not Go 1.7. I'm not sure if I should build my own version of 1.6.x for this testing or rely on the packaged Fedora version.)

In theory this is trivial and I could have set it up in the time that it took me to write this blog entry. In practice, the idea of maintaining multiple Go toolchains and switching among them and so on is just annoying and painful enough that there's a part of me that wants to avoid it all. Surely I can avoid problems by being careful on my own, right? (The honest answer is no, not really, and I know that, but part of me is in denial.)

Comments on this page:

By David Sowder at 2016-10-23 09:27:13:

I would even go far as to try to support the previous LTS unless there's a very good and compelling reason for a software project not to.

If other shops are anything like the higher ed shop I work at, our sysadmins have too much to do to keep everything running the latest LTS. We've still got a lot of RHEL5.

By cks at 2016-10-24 11:54:35:

For personal projects, my view is that I'm not going to go as far as supporting the previous Ubuntu LTS (default) packaged version of Go because that's way too old. For example, Ubuntu 14.04 appears to default to Go 1.2 (although Go 1.6 is apparently available).

We don't have any Go code in production currently and are unlikely to get any, but if we did I'd probably advocate strongly for not basing it on really old Go versions for the old LTS versions we still run. Go moves too fast at the moment (both in the compiler and in the standard library), it's not particularly hard to build a current version, and it's generally easy enough to 'cross' compile for older Linux distributions.

(Frankly it would be kind of a pain in the rear to keep track of what bits of the standard library were safe to use in really old Go versions, and it would exclude some quite useful features.)

Written on 23 October 2016.
« The shutdown program on a modern systemd-based Linux system
How I've wound up being one of the people who don't update IoT firmware »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Oct 23 01:11:11 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.