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.

Agreed, I think

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:

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.