Ok, so what strategies do people use for coping with their development / build environments (even entire languages and stdlibs) changing every 6 months?
Is stability out of the window?
Is stability out of the window?
Which means you do something like:
$ gvm install go1.7
$ gvm use go1.7
$ go build myproj
Errors? Fix them - and in the meantime, just switch back:
$ gvm use go1.6
$ go build myproj
Of course, reality is often different. We have a very large Go monorepo at work, and we've run into almost every breaking-but-not-spec-changing change in the language since 1.4. We've had subtle changes in behavior cause panics in production, code that used CGO to stop compiling, third party libraries tripping the race detector when GOMAXPROCS=NUMCPU was introduced by default, etc.
The majority of changes/fixes have been pretty small, and I'd say it takes about a day of man-hours every six months to get us on the next release, which is a drop in the bucket.
We run a lot of static analysis on our code, which includes things like `go vet`, `go fmt`, etc. Between point releases, there's no guarantee that those tools aren't changing/adding tests and functionality, which has been one of the bigger sources in our work required to upgrade.
All in all, it really is a painless and usually positive procedure - a ton of those fixes were subtly broken things who's behavior has been clarified. I think of it as a positive thing.