[kolyshkin]

Since there is no go.mod, CI creates one on the fly using go mod init and go get. In addition, make docs doesn't work with Go 1.23+ (#1280), and the schema validator can't be built with Go 1.22+ (go get is no longer supported outside a module).

This PR:

1. Moves the schema validator to its own module (schema/validate), so that its dependency (gojsonschema) does not become a dependency of github.com/opencontainers/runtime-spec.
2. Adds go.mod with no dependencies, and the go directive set to the minimal Go version we support and test with (1.21), and removes go.mod creation from CI.
3. Bumps golangci-lint to v2.14 (same as ci: bump golangci-lint to v2.14 #1325), since v2.10 (built with go1.26) can't work with Go 1.27, which is now the stable version.

(if #1325 is merged first, it's trivial to rebase this one)

For users of specs-go, nothing changes: the module path stays the same, and there are no new dependencies.

Fixes #1280.

Previously: #1068 was closed in favor of #1069 (making specs-go a separate module with its own tags), which has not happened since 2020. As noted in #1069 (comment), the Go code here is just struct definitions and constants, so separate Go releases are unlikely to be needed; image-spec also has go.mod at the top level.

[tianon]

Does anyone use "validate" enough to make this worthwhile to maintain?

[thaJeztah]

We should look if we can rewrite this to github.com/santhosh-tekuri/jsonschema/v6. This module is no longer maintained (I can have a look if it's an easy rewrite)

[thaJeztah]

• ☝️ opened a quick follow-up for that; schema/validate: migrate to santhosh-tekuri/jsonschema/v6 #1327

[thaJeztah]

Does anyone use "validate" enough to make this worthwhile to maintain?

Good question as well; at least it's good to give it its own go.mod so that its dependencies don't become dependencies of the spec itself.

[giuseppe]

LGTM

[marquiz]

Thanks! LGTM

[thaJeztah]

As noted in #1069 (comment), the Go code here is just struct definitions and constants, so separate Go releases are unlikely to be needed; image-spec also has go.mod at the top level.

Yeah, it was for things like 869b2d5 (#1279), which was a breaking change at least from the Go API side (and definitely caused some breakage down the line), so would've warranted a V2. It's the tricky bit of trying to version two distinct API stabilities (Go API vs spec API) into a single tag.

Given that the spec version is already captured in code, technically we could have them separate

runtime-spec/specs-go/version.go

Lines 5 to 15 in fbb4178

	const (
	// VersionMajor is for an API incompatible changes
	VersionMajor = 1
	// VersionMinor is for functionality in a backwards-compatible manner
	VersionMinor = 3
	// VersionPatch is for backwards-compatible bug fixes
	VersionPatch = 0
	// VersionDev indicates development branch. Releases will be empty string.
	VersionDev = "+dev"
	)

[thaJeztah]

LGTM on having a go.mod; the "module version must match specs version" is still something to slightly consider though.

[AkihiroSuda]

Added this to v1.3.1 milestone, but maybe we should skip it and bump the version to v1.4

[sudo-bmitch]

Image-spec had a similar update a while back. It may make sense to move the validate code to a common location. If there's interest in doing that, we could open an issue with the TOB to setup a new repo and maintainers.

opencontainers/image-spec#1253

[thaJeztah]

overall, I think a "sub" module in this repo is OK; I think it's used in CI to verify the json-schemas are done correctly, and it's .. very little code; bit on the fence on moving to a separate repo, as the amount of boiler-plating / maintenance to keep that up may be more than the little amount of code in it (at a quick glance).