Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update go version at travis-ci #1335

Merged
merged 1 commit into from
Feb 21, 2017
Merged

update go version at travis-ci #1335

merged 1 commit into from
Feb 21, 2017

Conversation

mcuadros
Copy link
Contributor

@mcuadros mcuadros commented Feb 20, 2017

Travis is testing against 1.6.x and 1.7.x if the intent is test againts the last two stable version we should remove the 1.6 and add the 1.8

Also the tool being use for the validation of bash scripts (https://github.com/mvdan/sh) is only compatible with 1.7>

Also I added tip as an allowed to fail version

Signed-off-by: Máximo Cuadros <[email protected]>
@cyphar
Copy link
Member

cyphar commented Feb 21, 2017

Personally I would /prefer/ if we keep testing Go 1.6.x -- mainly because currently there are still stable distributions which use Go 1.6. Testing another version is fairly cheap compared to breaking things so downstreams need to deal with it.

Unfortunately the failures on master are because one of the tools we use (shfmt) are broken on 1.6.x. :/

@crosbymichael
Copy link
Member

crosbymichael commented Feb 21, 2017

@cyphar I don't think we need to support go 1.6. If people are using it then it can be their responsibility. There are many improvements with 1.7-1.8 and security fixes that we can take advantage of.

Also this is not a runtime issue, its a buildtime issue so its not an impact on users. Since we are pre 1.0 I think its an ok move to make, there is no reason to live on an old build of Go and not take advantage of the improvements.

LGTM

Approved with PullApprove

@cyphar
Copy link
Member

cyphar commented Feb 21, 2017

@crosbymichael Fair enough.

LGTM.

Approved with PullApprove

@cyphar cyphar merged commit e773f96 into opencontainers:master Feb 21, 2017
cyphar added a commit that referenced this pull request Feb 21, 2017
@mvdan
Copy link
Contributor

mvdan commented Feb 21, 2017

FWIW, you can have the best of both worlds. You can keep 1.6.x and any older Go releases as long as you only run tools like vet, gofmt and shfmt on the latest Go release. Running them on older releases is flakier and wastes resources anyway.

@mcuadros
Copy link
Contributor Author

Compiling against old version of Go, IMHO, is a bad practice. We must help to the language evolve fast, updating to the latest versions ASAP.

@mvdan
Copy link
Contributor

mvdan commented Feb 21, 2017

@mcuadros sure, but that's unrelated to supporting older Go versions :) Most projects support the last 2-3 minor releases, but you could just as well do 4 or more while adopting the newest version as soon as it's out.

@crosbymichael
Copy link
Member

The problem is that go stdlib changes and when you use a new package it breaks older versions anyways.

@mcuadros mcuadros deleted the travis branch February 21, 2017 22:14
wking added a commit to wking/runc that referenced this pull request Jan 25, 2018
The helper DRYs up the transition tests and makes it easy to get
complete coverage for invalid transitions.

I'm also using t.Run() for subtests.  Run() is new in Go 1.7 [1], but
runc dropped support for 1.6 back in e773f96 (update go version at
travis-ci, 2017-02-20, opencontainers#1335).

[1]: https://blog.golang.org/subtests

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/runc that referenced this pull request Jan 25, 2018
The helper DRYs up the transition tests and makes it easy to get
complete coverage for invalid transitions.

I'm also using t.Run() for subtests.  Run() is new in Go 1.7 [1], but
runc dropped support for 1.6 back in e773f96 (update go version at
travis-ci, 2017-02-20, opencontainers#1335).

[1]: https://blog.golang.org/subtests

Signed-off-by: W. Trevor King <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants