I think this is a major step in the right direction for the Go team. Shipping on time and being ruthless with what gets into a release will only help Go in the long-term.
For what it's worth, I think the entire Go core team has done an awesome job with releases, and pushing forward for improvements.
As noted in past emails to golang-dev and on golang.org/wiki/Go-Release-Cycle, the constraints above are stricter than in past cycles. An explicit goal is to ship the first beta on time, by May 31, instead of many weeks late as has been our past practice. (If the past pattern held, this release's first beta would be seven weeks late, or one week before the scheduled release date.)
Ok, so what strategies do people use for coping with their development / build environments (even entire languages and stdlibs) changing every 6 months?
Stability increases, in our case, we just update Go on our CI and we get smaller binaries, better performance as updates come in. The code is always backward compatible so our code always compile. We obviously make sure our test suite passes and don't see any regressions. It was nice to get http/2 for free in a recent update, especially with cloudFlare now supporting http/2 push.
Others already noted - it's backwards-compatible. But it's actually even a bit easier than that for an all-Go project. On Ubuntu, the easiest way to have go installed is to use gvm ( https://github.com/moovweb/gvm ).
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
It's impressively painless. I went from go1.4 to 1.6 without having to change a single line of code -- but the 'go vet' tool got better, so when I re-ran it, it pointed out a few things that I then fixed. The compile didn't break without them, notably.
I'll echo what a lot of people are saying, with some caveats. The Go language spec hasn't changed since 1.0 -- that means that, by and large, code written in the days of 1.0 will still compile in 1.6 (and should compile in 1.7).
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.
I'd like to note that all the issues you encountered are because newer versions of Go have exposed issues in your application code and dependencies (with the possible exception of the new cgo pointer passing restrictions).
Totally - I hope no one read it as anything otherwise. There's a wide chasm of "change" that can happen without the spec changing, was my main point.
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.
the main changes are related to the SSA compiler backend and smaller binary files. 1.7 should also better support binary only packages (so vendors can sell compiled packages without providing sources, it kinda works right now but was hacky/buggy).
Can we make a community list about topics that we can criticize the Go core team for and also add a priority ranking for topics that deserve the most scorn?
24 comments
[ 2.8 ms ] story [ 40.6 ms ] threadFor what it's worth, I think the entire Go core team has done an awesome job with releases, and pushing forward for improvements.
As noted in past emails to golang-dev and on golang.org/wiki/Go-Release-Cycle, the constraints above are stricter than in past cycles. An explicit goal is to ship the first beta on time, by May 31, instead of many weeks late as has been our past practice. (If the past pattern held, this release's first beta would be seven weeks late, or one week before the scheduled release date.)
Is stability out of the window?
[1] https://golang.org/doc/go1compat
Which means you do something like:
It's impressively painless. I went from go1.4 to 1.6 without having to change a single line of code -- but the 'go vet' tool got better, so when I re-ran it, it pointed out a few things that I then fixed. The compile didn't break without them, notably.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.
runtime: support symbolic backtrace of C code in a cgo crash (CL 17761)
| add support for Fortran (CL 19670, CL 4114)