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

Declare supported Go versions #899

Open
stevvooe opened this issue Mar 1, 2022 · 4 comments · May be fixed by #1225
Open

Declare supported Go versions #899

stevvooe opened this issue Mar 1, 2022 · 4 comments · May be fixed by #1225

Comments

@stevvooe
Copy link
Contributor

stevvooe commented Mar 1, 2022

#885 exposed the problem that we don't have a declaration of our supported Go versions for the provided packages.

Let's add a document somewhere that can declare the current set of supported go versions.

@Humod55

This comment was marked as spam.

@sudo-bmitch
Copy link
Contributor

I think the current view is to not update the go.mod version unless we make a change that requires new functionality.

It would probably be good to clarify that we will not adopt a new feature that increments the version beyond a certain point. In my personal projects, I've been supporting 3 minor Go releases (2 officially supported by Go, and 1 more to give any dependencies extra time to upgrade).

I'm flexible on how many versions we want to support, since I know there are a lot of projects out there with slower upgrade cycles. But there's also no requirement for projects building with unsupported Go compilers to upgrade to the latest image-spec release, so we don't need to be too slow.

@tianon
Copy link
Member

tianon commented Dec 11, 2024

Agreed, I think

go 1.18
is sufficient here, and staying conservative unless we have a real technical reason not to gives consumers more flexibility.

@sudo-bmitch
Copy link
Contributor

I'm seeing three potential places we can call this out. The go.mod is one, though I get nervous that others only maintain this file with automation and wouldn't see the comment, but it would at least stand out in a PR.

Next is our GHA:

# current Go releases plus the version in the go.mod are tested

And last that I'm seeing is the hacking doc: https://github.com/opencontainers/image-spec/blob/5325ec48851022d6ded604199a3566254e72842a/HACKING.md#go

Of all of those, I think the go.mod is fine, and updating the pointer in the GHA and hacking doc to point to the go.mod so we only maintain one authoritative location.

I'll submit that PR, and opt for a minimum of 3 minor Go releases to be supported. So if there's a new feature we want, that requires waiting for the next two minor Go releases to go out first.

@sudo-bmitch sudo-bmitch linked a pull request Dec 12, 2024 that will close this issue
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 a pull request may close this issue.

4 participants