build: upgrade to Go 1.7 #487
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Stephen J Day <[email protected]>
|
PTAL @opencontainers/image-spec-maintainers |
|
This is presumably to address an expansion of the test API [1]. But
if we are attempting to provide a ChainID package for external
consumption, I think it might make more sense to have an
implementation/test-suite which worked on a range of recent Go
versions.
[1]: #486 (comment)
|
|
@wking Go 1.7 has been out since August. By the time the specification is released, Go 1.8 will be out. Since these are in-project tests and we don't provide any backwards compatibility for Go versions, we should target the latest possible. Note that these packages will be consumable by pre-Go 1.7, anyways, since they don't consume tests. Anyways, I would kindly ask that you stop wasting my time. |
|
On Thu, Dec 08, 2016 at 02:34:59PM -0800, Stephen Day wrote:
Since these are in-project tests and we don't provide any backwards
compatibility for Go versions…
If no Go backwards compatibility is the project policy, then that's
fine. Do we document that anywhere?
Note that these packages will be consumable by pre-Go 1.7, anyways,
since they don't consume tests.
I'm hesistant about “don't worry, this works on Go <1.7, we just don't
test it there”. Travis makes a build matrix pretty easy, so we can
test this in as many flavors of Go as the project decides to support.
|
|
LGTM |
1 similar comment
|
LGTM |
wking
added a commit
to wking/image-spec
that referenced
this pull request
Dec 14, 2016
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. The Go-compat policy formalizes the rough sketch from [1]. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.5, we don't care or want some awkward workaround. But if it breaks on Go 1.6 we do care and want a patch. And if someone wants to genericize our test suite to run on both 1.6 and 1.7, we want a patch for that too. [1]: opencontainers#487 (comment) Signed-off-by: W. Trevor King <[email protected]>
wking
added a commit
to wking/image-spec
that referenced
this pull request
Dec 16, 2016
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.6, we don't care or want some awkward workaround. But if it breaks on Go 1.7 we do care and want a patch. The Go-compat policy formalizes [1]. Previous maintainer comments suggested some support for older Go releases [2], and I personally think we want to give people more flexibility (not everyone can upgrade to a new Go version on the day it comes out), but this commit at least documents where we are now as a base for future discussion. [1]: opencontainers#500 (comment) [2]: opencontainers#487 (comment) Signed-off-by: W. Trevor King <[email protected]>
dattgoswami9lk5g
added a commit
to dattgoswami9lk5g/bremlinr
that referenced
this pull request
Jun 6, 2022
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.6, we don't care or want some awkward workaround. But if it breaks on Go 1.7 we do care and want a patch. The Go-compat policy formalizes [1]. Previous maintainer comments suggested some support for older Go releases [2], and I personally think we want to give people more flexibility (not everyone can upgrade to a new Go version on the day it comes out), but this commit at least documents where we are now as a base for future discussion. [1]: opencontainers/image-spec#500 (comment) [2]: opencontainers/image-spec#487 (comment) Signed-off-by: W. Trevor King <[email protected]>
7c00d
pushed a commit
to 7c00d/J1nHyeockKim
that referenced
this pull request
Jun 6, 2022
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.6, we don't care or want some awkward workaround. But if it breaks on Go 1.7 we do care and want a patch. The Go-compat policy formalizes [1]. Previous maintainer comments suggested some support for older Go releases [2], and I personally think we want to give people more flexibility (not everyone can upgrade to a new Go version on the day it comes out), but this commit at least documents where we are now as a base for future discussion. [1]: opencontainers/image-spec#500 (comment) [2]: opencontainers/image-spec#487 (comment) Signed-off-by: W. Trevor King <[email protected]>
7c00d
added a commit
to 7c00d/J1nHyeockKim
that referenced
this pull request
Jun 6, 2022
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.6, we don't care or want some awkward workaround. But if it breaks on Go 1.7 we do care and want a patch. The Go-compat policy formalizes [1]. Previous maintainer comments suggested some support for older Go releases [2], and I personally think we want to give people more flexibility (not everyone can upgrade to a new Go version on the day it comes out), but this commit at least documents where we are now as a base for future discussion. [1]: opencontainers/image-spec#500 (comment) [2]: opencontainers/image-spec#487 (comment) Signed-off-by: W. Trevor King <[email protected]>
laventuraw
added a commit
to laventuraw/Kihara-tony0
that referenced
this pull request
Jun 6, 2022
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.6, we don't care or want some awkward workaround. But if it breaks on Go 1.7 we do care and want a patch. The Go-compat policy formalizes [1]. Previous maintainer comments suggested some support for older Go releases [2], and I personally think we want to give people more flexibility (not everyone can upgrade to a new Go version on the day it comes out), but this commit at least documents where we are now as a base for future discussion. [1]: opencontainers/image-spec#500 (comment) [2]: opencontainers/image-spec#487 (comment) Signed-off-by: W. Trevor King <[email protected]>
tomalopbsr0tt
added a commit
to tomalopbsr0tt/fabiojosej
that referenced
this pull request
Oct 6, 2022
The links help with discoverability, otherwise folks reading the README might not notice that we provided these resources in addition to the spec itself. By declaring a Go-compat policy, folks who have Go troubles can tell without testing whether the image-spec tooling *should* work for their Go environment. And if/when it does not, they can see whether image-spec is interested in patches or not. For example, if the tooling breaks on Go 1.6, we don't care or want some awkward workaround. But if it breaks on Go 1.7 we do care and want a patch. The Go-compat policy formalizes [1]. Previous maintainer comments suggested some support for older Go releases [2], and I personally think we want to give people more flexibility (not everyone can upgrade to a new Go version on the day it comes out), but this commit at least documents where we are now as a base for future discussion. [1]: opencontainers/image-spec#500 (comment) [2]: opencontainers/image-spec#487 (comment) 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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Stephen J Day [email protected]