-
Notifications
You must be signed in to change notification settings - Fork 663
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
schema: use Go's embed package instead of esc #885
Conversation
Signed-off-by: Stephen Day <[email protected]>
@@ -1,18 +1,14 @@ | |||
module github.com/opencontainers/image-spec | |||
|
|||
go 1.11 | |||
go 1.16 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm okay with this because we just cut a release that older versions of go can continue to use, but I can imagine this being controversial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's a good call out but is a requirement to use go:embed
. If we don't want to move the req up to 1.16, we should leave esc in place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a spot check of dependencies and it looks like most are 1.16, some at 1.17, but there are some projects still at 1.14 and 1.15. Given that 1.15 is no longer officially supported by the Go, I'm okay with this myself.
This looks good to me, but let's hold as I don't doubt some projects are still supporting older than go1.16 versions out there. |
What horizon do want to maintain here? That's probably a very large question. ;) |
@cyphar PTAL |
since any changes here would still eventually need to be tagged for a release, I think having a trailing number of go releases is good. Currently go1.18 is about to be released. So bumping to go1.16 would mean 3 versions of go, which is likely suitable. And maybe by the time this would get tagged to a release for image-spec, there may be another release out by then? |
+100. Rather than waiting for the long tail to be cleaned up, a policy of a 3-4 supported releases sounds good to me. We aren't breaking existing projects since they can continue to use old image-spec tags. And the versions of Go they are running aren't supported by the Go developers. |
@sudo-bmitch @vbatts Ok, sounds like we'll hold off on merging this until 1.18 is released. I've added #899 to cover the need for supported versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get a follow-up PR with words on perhaps at least supporting the last three go releases
Signed-off-by: Stephen Day [email protected]