Decide on golang version strategy

[jodh-intel]

Minimum supported version of golang

Currently, https://github.com/kata-containers/documentation/wiki/Developer-Guide#assumptions states we support "golang version 1.8.3 or newer.".

Range of golang versions supported

We need to decide on a strategy for determining which versions of golang we support:

$ cd $GOPATH/src/github.com/kata-containers
$ cat */.travis.yml|grep -A 4 "go:"|sed 's/^ *//g'|egrep -- "- (1.[0-9]|tip)"|sort -u 
- 1.8
- 1.9
- tip

Consistency

What isn't clear from the uniq(1)'d list above is that different components are testing with a different range of golang versions.

Introduce Process

We should be fine to retain go1.8.3 as our minimum version, but we do need a process to decide:

• how we decide the range of go versions we support.
• how we move to a new version for CI/PnP.
• how we remove old versions.

Something similar to:

• https://github.com/clearcontainers/runtime/wiki/Handling-new-and-end-of-life-distro-versions

How do we handle the "bleeding edge"?

There is also the issue of whether we test with golang "tip" or not, and if we do, whether that should block a PR (probably not):

• https://github.com/kata-containers/ksm-throttler/blob/master/.travis.yml#L3..L6

Travis-specifics

The problem becomes easier to manage once we move away from Travis (see kata-containers/ci#4) as we can centralise the logic rather than having 'n' different .travis.yml files to manage...

Where to store range of golang versions

Note that ideally we would specify a list of supported golang versions in a file like a versions.txt database (see kata-containers/runtime#11).

That way, we can have a central list that everything else that needs to know this version range can consume, namely:

Consumers of golang versions list

• Developer documentation and scripts.
• QA CI scripts for all repositories
  (where all code repos would defer to https://github.com/kata-containers/tests/tree/master/.ci to determine the details, as usual).
• Metrics CI.
• Packaging scripts in https://github.com/kata-containers/packaging
  (to ensure the same version of golang is used as the version the code was tested with).
• Packaging CI.

[sameo]

Can we simply say we support tip, and the 2 last released golang versions?
cc @markdryan

[rbradford]

FYI, you'll need to refer to 1.10 and later as "1.10" in the yaml file otherwise you'll get 1.1

[markdryan]

Can we simply say we support tip, and the 2 last released golang versions?

Sounds reasonable to me and it's pretty much what I do with the other projects. As the go releases stick to a strict schedule, two releases a year, one in Feb and one in August, the date on which kata-containers would drop support for an older go release would always be predictable; i.e., 1.10 would be supported until Feb 2019.

There's one other thing to be aware of with Go 1.10. There have been some changes to gofmt. If you have three index slices anywhere in your code and you check the formatting of go code in your travis file, you may find it tricky to get the builds to pass on both 1.9 and 1.10. See https://golang.org/doc/go1.10#gofmt

[jodh-intel]

I think we might be able to close this issue now that we have:

• https://github.com/kata-containers/runtime/blob/master/versions.yaml#L131..L136

... which lists the current version of go, plus the newest version we can work with. What do we think?