Proposal: separate go implementation tagging from specification itself

[thaJeztah]

Related to #1052 and #1068

Currently, this repository tags releases for the runtime spec itself, however, the go implementation of the specification also resides in this repository.

While it's good to have both living in the same repository, sometimes changes in the go implementation may be desirable that don't relate to a change in the specification itself (bugfixes, updated dependencies, enhancements).

My proposal is to tag the go implementation separate from the specification.

Given that the go implementation lives in a subdirectory, this could be done by making it a submodule, and using prefixes for the tags; tags for the go implementation would be prefixed with specs-go/

• new prefixed tags can be created for each existing tag (v1.0.0 -> specs-go/v1.0.0, v1.0.1 -> specs-go/v1.0.1)
• a go.mod can be placed inside the spec-go directory, to make it its own module

Note that the Go implementation contains the version of the runtime-spec that it implements; https://github.com/opencontainers/runtime-spec/blob/v1.0.2/specs-go/version.go, so the version if the specification can be identified once the tagged releases of the go module diverge from the runtime spec.

Go modules require SemVer to be applied (at the Go API level), so breaking changes require the "major" version component to be updated, and feature additions in the Go code should increment the "minor" version component. Given that go modules look from the Go API perspective, it's likely that the versions will diverge (e.g., v2.0.0 of the specification may be fully backward compatible with v1.x.x, so strictly wouldn't require a major version update of the go implementation).

I realise this could confuse users, so proper documentation / inclusion in the README with a comparison table would be good to have

[mikebrow]

SGTM

[kolyshkin]

LGTM

[vbatts]

I'm for this, but it adds to the release process, which I had to make a checklist for.

It seems some of this can be done in phases, right? Like, we don't need to split out a git-submodule initially. But could make tags for past releases?

[AkihiroSuda]

While it's good to have both living in the same repository, sometimes changes in the go implementation may be desirable that don't relate to a change in the specification itself (bugfixes, updated dependencies, enhancements).

The Go codes in the runtime-spec repo only contain the struct definitions and the constants, so it is unlikely to have such changes?

[AkihiroSuda]

image-spec and distribution-spec already have go.mod:

• https://github.com/opencontainers/image-spec/blob/main/go.mod
• https://github.com/opencontainers/distribution-spec/blob/main/specs-go/go.mod