release 0.9.1

[cyphar]

This is a patch release branched off from 0.9.0 with only a few commits backported/recreated:

• A recreation of the move to go.mod from #727 (specifically commit 0e5956de9511).
• A backport of #706 to add support for Process.Umask.
• A bump to runtime-spec 1.0.2.

As far as I can tell, there were no other patches necessary to add support for 1.0.2, so we can just do this patch release to ensure there is a go install-able version of runtime-tools while we work on the 0.10 release that supports runtime-spec 1.1.0.

This release is going to be done on a release-0.9.1 branch that will only exist for the purpose of this release. The alternatives (as outlined by @thaJeztah in #771) are quite ugly and it seems far simpler to just have a very small patch release with go.mod and the few changes needed for 1.0.2 support, rather than trying to revert patches to get us back to 1.0.2 support.

[cyphar]

It's possible we also need to backport #733 -- @kolyshkin wdyt?

[thaJeztah]

Thanks! Generally, I'm good with this approach if we want to have a version with a go.mod.

I should mention that there's one (BIG) caveat here; go module "pseudo versions", and I recall I ran into a similar situation with the image-spec when a release was done from a release branch;

currently, any "version" from master / main that's taken from "ahead of v0.9.0" will get a dreamed-up-by-go-modules version of v0.9.1-..., such as:

	github.com/opencontainers/runtime-tools v0.9.1-0.20221107090550-2e043c6bd626

Because.. well go modules think code is linear, and nobody uses release branches, and those commits rank "older than" v0.9.1, so once we do a v0.9.1 release, any project that uses a commit from master will now be downgraded to v0.9.1.

Similarly, once this PR is merged, and if it's not tagged, the pseudo version will also be v0.9.1-..., but with a datestamp followed that's newer than pseudo versions that projects use currently, which means that any indirect dependency that would use that pseudo-version can also cause your module to be downgraded.

(Honestly, I WISH go modules didn't make that mistake of making up versions, and instead would've just stuck with v0.0.0-<sha> for any pseudo version (i.e.: we cannot make any assumptions about versions for an unreleased commit they're not comparable because neither "date" nor "version" makes sense when comparing separate branches)

[thaJeztah]

So I think the recommended "solution" to that from the Go maintainers is to tag the immediate commit after a tag (or release-branch) as v<next-version>-alpha.0. So that pseudo versions are generated relative to that;

When a release branch is created (e.g. a v0.9 release and the main branch is targeting v0.10, then the main branch must be tagged as v0.10.0-alpha.0

But of course; that, well, defeats the whole idea of SemVer (can't know the version ahead of time!), and for this repository I also have no idea what that means for existing v0.9.1- pseudo versions; do they become invalid? 🤔

[cyphar]

Ah, that's a good point. We talked about all of these unfortunate behaviours in the spec repo a few months ago, I completely forgot about this issue...

I think we can avoid that particular issue by doing something like v0.9.1-0.1.hotfix, which will sort lower than the Go pseudo-version, avoiding downgrades. It would be quite ugly for users to actually use, but at least there will be some tagged version a user could reference with go.mod.

[kolyshkin]

It's possible we also need to backport #733 -- @kolyshkin wdyt?

I have a 0.10.0 draft (https://github.com/opencontainers/runtime-tools/releases/tag/untagged-2451375cc40c0b4a3eab) sitting there for quite a while; I think it makes sense to release it right after 0.9.1.

[kolyshkin]

Or, we can just do 0.10.0 from a current HEAD and deal with the consequences...