README: Link to specs-go and schema and declare Go-compat policy #500
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
|
Travis failure is a Docker timeout while fetching the pandoc image. Kicking Travis should fix it. |
|
This policy should be the most recent version of Go, for now. We already have a lot of versioning to deal with and having to worry about Go laggards will put too much burden on the project. |
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]>
wking
force-pushed
the
document-go-compat
branch
from
41b47f6 to
6191aff
Compare
|
On Fri, Dec 16, 2016 at 11:38:15AM -0800, Stephen Day wrote:
This policy should be the most recent version of Go, for now.
Updated with 41b47f6 → 6191aff.
I personally hope the “for now” here goes away quickly (in a
subsequent PR). Dropping existing consumers as soon as a new version
of Go is released doesn't give me that “we care about backwards
compat” feeling ;). And we don't have all that much Go code, so it
seems unlikely that the spec-provided Go *has* to live on the bleeding
edge.
|
|
@wking Go isn't really like other languages. There is really no excuse to not upgrade. We can do build flags, but, this case, it was just test features. |
|
On Tue, Dec 20, 2016 at 12:15:53PM -0800, Stephen Day wrote:
Go isn't really like other languages. There is really no excuse to
not upgrade.
This seems unlikely to me ;), see the caveats in [1]. But I'm trying
to punt whether we *should* have backwards compat to a later issue;
this PR just documents the *current* policy [2].
[1]: https://golang.org/doc/go1compat#expectations
[2]: #500 (comment)
|
|
There are absolutely valid reasons not to immediately upgrade Go when a new version is out. Pretty sure Docker has been in this situation before :-). In any case, I'm "okay" with this change - it's vague enough to leave it as caveat lector. |
|
LGTM |
Yes, I believe there was some problems moving to Go 1.5 or 1.6. But we never forced this requirement on our dependencies because we vendored. I would say most recent minus one would be acceptable, as well. |
|
LGTM |
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.
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 here. 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.
And I'm just guessing at 1.6. Maybe the repo-policy is to support 1.5+? Something else?