update runtime-spec v1.1.0

[thaJeztah]

• depends on go.mod: golang.org/x/sys v0.1.0 #773

Update some dependencies to released versions;

go.mod: github.com/opencontainers/runtime-spec v1.1.0

full diff: opencontainers/runtime-spec@86290f6...v1.1.0

[thaJeztah]

@kolyshkin @mrunalp ptal 🤗

[cyphar]

Can we do a release without this change, and then another release with this change? The lack of a release with go.mod means that you cannot use go install to get a 1.0.2-compatible runtime-tool validator (0.9 doesn't have a go.mod so you pull the 1.1.0 spec which causes runtime-tools to think that it is a 1.1.0 spec validator). This is currently breaking umoci's CI, and will be an issue for historical users that need the older spec version.

[cyphar]

Or, we can put the golang.org/x/sys update into a separate PR. I'll cherry-pick it to an update PR...

[thaJeztah]

OHMAN, I completely forgot v0.9.0 didn't have a go.mod

Or, we can put the golang.org/x/sys update into a separate PR. I'll cherry-pick it to an update PR...

At least that won't hurt; I opened #773

[thaJeztah]

As to the runtime-spec version, that's a really tricky one, and puts us in a rather awkward spot if you want to have a release with a go.mod that also has a "somewhat sensible" version of the spec, because currently, it's neither v1.0.x nor v1.1.x, and it's using a version that was never released as part of a v1.0.x;

Looking at the v0.9.0 release, that's slightly better, as it uses a commit that's still v1.0.x (v1.0.1-57-g1722abf);

runtime-tools/Godeps/Godeps.json

Lines 36 to 40 in ee63cfa

	{
	"ImportPath": "github.com/opencontainers/runtime-spec/specs-go",
	"Comment": "v1.0.1-57-g1722abf",
	"Rev": "1722abf79c2f8f2675f47367f827c6491472cf27"
	},

Which is somewhere between v1.0.1 and v1.0.2 of the spec;

• opencontainers/runtime-spec@v1.0.1...1722abf
• 68 commits behind v1.0.2 opencontainers/runtime-spec@1722abf...v1.0.2

Looking at the first possible commit to tag with a go.mod included (go.mod was added in 0e5956d);

That already gives us a version of the spec that's a v1.1.x ("ish"), because it's ahead of v1.0.2 (the last v1.0.x release)

• 41 commits ahead of v1.0.2 opencontainers/runtime-spec@v1.0.2...7413a7f
• 79 commits behind v1.1.0-rc.1 opencontainers/runtime-spec@7413a7f...v1.1.0-rc.1

If you depend on the version in the spec source, then I wonder if any reasonable expectations can be deducted from that 🤔

So, I guess if the goal is to;

• have a tagged version of runtime-tools
• with a go.mod
• that includes a v1.0.x version of the space (v1.0.2), and NOT a v1.1.x version

Then I THINK the only "real" solution would be to

• create a (temporary) release branch that we fork of an older version
• downgrade the version of the spec to v1.0.2
• ^^ which may involve reverting some features that depend on v1.1.x of the spec (to be looked at)

The alternative would be to "move forward", and;

• update the spec to v1.1.0
• do a release (first release with a go.mod and v1.1.0 of the spec)

[cyphar]

We could fork from 0.9 and release a 0.9.1 that "just" does the go.mod migration and upgrades to 1.0.2 (with cherry-picking if absolutely necessary). That way, we won't have to worry about reverting things from main and 0.10.0 could be a strict upgrade.

That being said, given that 0.9 was also a release that had a non-released spec version I think it's not too crazy to just say that 0.10 can similarly just be a fruity intermediate runtime-spec version in keeping with all of the other releases of runtime-tools, and we will stop doing that in future releases.

[cyphar]

Based on looking at the git logs, there was actually only one patch "needed" for us to support v1.0.2, so that approach seemed much simpler. See #774.

[cyphar]

On reflection, just doing this is a better idea.

[kolyshkin]

LGTM