Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release 0.9.1 #774

Open
wants to merge 5 commits into
base: release-0.9.1
Choose a base branch
from
Open

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Sep 15, 2023

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

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 and others added 5 commits September 15, 2023 16:58
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]>
@cyphar cyphar mentioned this pull request Sep 15, 2023
1 task
@cyphar
Copy link
Member Author

cyphar commented Sep 15, 2023

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

@thaJeztah
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

cyphar commented Sep 15, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants