release 0.9.1 #774
release 0.9.1 #774
Conversation
This ensures that modern Go users can actually get the versions of our dependencies we have pinned when doing "go install". NOTE: This commit only exists in the release-0.9.1 branch of runtime-tools. The corresponding commit in main is commit 0e5956d ("Switch from Godeps to go modules"). Signed-off-by: Aleksa Sarai <[email protected]>
Update our spec version to a properly released spec, in preparation for the 0.9.1 release. NOTE: This commit only exists in the release-0.9.1 branch of runtime-tools. There is no real corresponding commit in main, as we have historically not tracked the runtime-spec per-release. Commit 43243fe ("Add missing interface to set init processes Umask") did update main to 1.0.2 but there were other patches necessary to support all of the spec features in 1.0.2. Signed-off-by: Aleksa Sarai <[email protected]>
Umask is a field specified in the runtime spec, but we don't have a method to set it in runtime-tools. Some users might want to modify the default Umask of a container. Cherry-pick of commit 43243fe ("Add missing interface to set init processes Umask"). Signed-off-by: Daniel J Walsh <[email protected]> [cyphar: rebased on top of release-0.9.1] Signed-off-by: Aleksa Sarai <[email protected]>
Signed-off-by: Aleksa Sarai <[email protected]>
Signed-off-by: Aleksa Sarai <[email protected]>
|
It's possible we also need to backport #733 -- @kolyshkin wdyt? |
|
Thanks! Generally, I'm good with this approach if we want to have a version with a 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 Because.. well go modules think code is linear, and nobody uses release branches, and those commits rank "older than" Similarly, once this PR is merged, and if it's not tagged, the pseudo version will also be (Honestly, I WISH go modules didn't make that mistake of making up versions, and instead would've just stuck with |
|
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 When a release branch is created (e.g. a 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 |
|
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 |
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. |
|
Or, we can just do 0.10.0 from a current HEAD and deal with the consequences... |
This is a patch release branched off from
0.9.0with only a few commits backported/recreated:go.modfrom Migrate to go mod #727 (specifically commit 0e5956d).Process.Umask.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 ofruntime-toolswhile 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.1branch 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 withgo.modand the few changes needed for 1.0.2 support, rather than trying to revert patches to get us back to1.0.2support.