4 ms·
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 th
by manacit 10y ago
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.
- enneff 10y agoI'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).
- manacit 10y agoTotally - 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.