
Go 1.7 freeze announced - vruiz
https://groups.google.com/forum/#!topic/golang-dev/lcvpM-vAoE8
======
rdegges
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.

~~~
ivoras
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?

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

~~~
manacit
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.

------
kevinmgranger
Is there a work-in-progress changelog of what we can expect to see in 1.7? I
couldn't find one.

~~~
4ad
Very incomplete:
[https://tip.golang.org/doc/go1.7.txt](https://tip.golang.org/doc/go1.7.txt)

~~~
weitzj
Now what does that mean? What does Fortran have to do with Go?

| add support for Fortran (CL 19670, CL 4114)

~~~
4ad
You can now call Fortran code through cgo, from Go.

