Minimum supported Go version

[acln0]

This matter came to light with the submission of #17. In reworking the tests, I unfortunately omitted the fact that Go < 1.7 doesn't have subtests, so the Travis builds for < 1.7 are failing.

In the context of that PR, I think the relevant questions are whether or not testing for Go >= 1.3 && Go < 1.7 adds value for users who are stuck on those versions, and whether they'd be comfortable using the package if regular tests only run on Go >= 1.7.

If we assume that the package will have users in that category, and we believe the answer to the former question to be "yes" (and the answer to the latter to be "no"), then I can refactor the tests to work on < 1.7.

On the other hand, subtests are a nice modernization, and they fit the nature of the tests quite well.

If the subtests stay, the documentation w.r.t. supported versions could read "tested on >= 1.7, probably works on >= 1.2". If we remove subtests, the documentation will continue to say "tested on >= 1.3, probably works on >= 1.2".

Thoughts?

[theckman]

We could follow the same policy as the Go authors themselves: https://golang.org/doc/devel/release.html#policy

If we deem that too aggressive, I think we should keep subtests and drop testing for < 1.7. We can change the README like you mentioned.

[niaow]

I believe we should be fine dropping any pre-context go versions, because many go packages do not work with those go versions. However we should also consider the usage of 1.6 as the default version in some distros (ubuntu. . .).

[niaow]

If we decide to support older go version, we will need to write a subtest helper that would provide similar functionality on older versions. This would however get extremely annoying for outside contributors.

[theckman]

@jadr2ddude I think a piece of data we could dig in to, if we wanted to, is how many issues people have using Go 1.6 is and what the workarounds are. The ones I can recall from Slack ended up with needing a newer version of the toolchain installed, or they resulted to things like maintaining two copies of the files guarded by build tags.

The point I'm going after is that trying to use these older toolchains has been troublesome, so maybe we'd be good to drop testing for them.