Add back support for Go 1.6

[broady]

If the cost is pretty low, could you add it back?

Go 1.8 isn't the default on GAE yet (but will be soon)

Go 1.6 will continue to be available (opt-in) for at least several months, and the Cloud teams need to continue support for 1.6 for several packages that depend on gRPC. This complicates things for customers, as they'll need to pin to the last version of grpc-go that supported 1.6.

[broady]

/cc @jba @zombiezen @rakyll

[dfawley]

Rolling back the PR that removed 1.6 support is obviously trivial. However, there is an ongoing maintenance cost in the form of fragmented (conditionally-built) code and needing to maintain workarounds for Go 1.6 bugs (notably golang/go#15078).

Is vendoring the previous release not an option for you if you need 1.6 support?

[broady]

I should have made it more clear: I work on the Cloud team - on App Engine and on Google and GCP client libraries.

Our customers will need to pin back to an old version. And yes, we all agree they should be doing that already.

How about some nominal support for 1.6 - that is, still drop "support" for 1.6, but any bugs that arise are fixed with only a best-effort guarantee.

[dfawley]

How about some nominal support for 1.6 - that is, still drop "support" for 1.6, but any bugs that arise are fixed with only a best-effort guarantee.

Such a change wouldn't actually help with any of my maintenance concerns. We'd have to revert the PR that dropped 1.6 compatibility and continue to maintain a more complex code base. I also fully expect our dependencies to drop 1.6 compatibility in the near future (x/net/trace broke 1.6 builds a few months back, but reverted it, and IIRC there was a comment somewhere that said they were going to roll forward after the final 1.9 release). If our dependencies don't support 1.6, then we can't.

I don't really see any compelling reasons to maintain Go1.6 compatibility at HEAD. Anyone that wants to run with 1.6 can pretty easily vendor to the previous grpc-go release (1.6, interestingly enough). Is there something that I'm missing here?

[broady]

Yes, we reverted x/net/trace back to 1.6 because of App Engine.
(note, you'll see I'm the reviewer on the rollback CL)

"can pretty easily vendor" - as you know, the dependency management situation for Go isn't quite that straightforward at the moment.

[dfawley]

We debated this for awhile and decided to roll back the change early next week and do one more release with Go1.6 support (in 6 weeks).

[jba]

When you do drop 1.6, you should not also change "golang.org/x/net/context" to "context". It is true that "context" was introduced in 1.7, but there may still be users who use recent versions of Go (even 1.9) but who still are on golang.org/x/net/context, because one of their dependencies is.

In other words, dropping 1.6 support is not a breaking change for a 1.9 user, but changing the context import path may be.

I believe we have to wait for 1.10 to come out, at which point we can assume everyone is on 1.9 or 1.10, and therefore everyone has type aliases. Then we will make golang.org/x/net/context an alias for the stdlib context, and only then can we change import paths.

[dfawley]

@jba, this is discussed in #711, and we will not be doing this until our oldest supported version is 1.9 (see: my comment). Thanks.

[dfawley]

FYI, gomock no longer works with Go1.6 either: golang/mock#116

[balshetzer]

I was convinced to restore backwards compatibility in golang/mock#118

[dfawley]

Note that in 21 days, and after our next release (Oct 23rd), we will be dropping support for Go1.6-1.8.

Since this thread is locked, head over to issue #711 for related discussion if desired.