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.)

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, Add Comment.
Search:
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.