Proposal: separate go implementation tagging from specification itself #1069
Description
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-godirectory, 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