Repository navigation
Prepare / Tag v1.1.0 release #1052
Description
(related to https://github.com/containerd/containerd/pull/4357/files#r448837520)
Runc tagged a new release (v1.0.0-rc91), and is currently depending on a non-tagged version of the runtime-spec. With various distribution packagers requiring tagged releases, and with go modules encouraging consumers to packages to use tagged releases, I'm wondering if a new release should be tagged.
runc is currently consuming 237cc4f, (changes since v1.0.2: v1.0.2...237cc4f), but there's a couple more changes in master (237cc4f...master)
Are there pending pull requests that should be merged before tagging v1.0.3? (perhaps #1046 would be nice to have). tags should be "cheap" so, perhaps not a blocker for a v1.0.3, but suggestions welcome 🤗
Activity
h-vetinari commentedon Jul 2, 2020
Not to further hold up an already long process, but #1040 should also be very close to finished (just waiting for final review).
AkihiroSuda commentedon Jul 2, 2020
#1040 should be probably v1.0.4 or later
thaJeztah commentedon Jul 2, 2020
Given that it's adding new features, #1040 should probably bump the minor version to stick with SemVer (so
v1.1.0)thaJeztah commentedon Jul 2, 2020
Thinking of that, possibly #1046 warrants a "minor" version bump as well, as it's adding new functionality.
[-]Prepare / Tag v1.0.3 release[/-][+]Prepare / Tag v1.0.3 (or v1.1.0) release[/+]cyphar commentedon Jul 2, 2020
Yeah, we should tag a
1.0.3. I would like to see #1046 merged (I don't think it makes sense to refer to it as a new feature -- it's just defining Go constants that were already defined by the spec -- though arguably the new hooks we added should've made the last release a1.1.0). And yeah, #1040 should definitely wait -- I don't want to rush adding more logic to cgroup configuration until we're sure it makes sense.mskarbek commentedon Jul 2, 2020
@cyphar what more do you expect from croupv2 work?
cyphar commentedon Jul 2, 2020
@mskarbek We need to have at least one implementation of it so that we can be sure that the specification changes actually work on real systems, and if they don't work we should go back and fix issues we may find in the specification. In addition, it wouldn't hurt to talk to other container runtimes (such as LXC) to get their feedback since they've supported cgroupv2 for much longer than any OCI runtime.
EDIT: Ignore this section, it's pretty much gibberish. I shouldn't write comments while I'm still half-awake...
And looking at the PR right now, we also need to address how to deal with unknown configuration values. Currently it says that:
But also:
Which could in theory conflict in the future if there is a controller that requires some extra setup other than writing its name to
cgroup.controllers. We need to make sure we don't cause future headaches for ourselves while also allowing people to configure cgroupv2 controllers without needing endless runtime-spec updates (which is why I was on board with the current proposal and have discussed doing it this way off-line for some time).Remember, once something is in the runtime-spec we cannot remove it (without a major version bump) -- shoe-horning it in would be a mistake.
AkihiroSuda commentedon Jul 3, 2020
The v1-to-v2 conversion convention can be cherry picked to v1.0.3?
thaJeztah commentedon Jul 3, 2020
@AkihiroSuda which change is that? Do you have a specific PR?
Looking at the changes since the last release; v1.0.2...8e2f17c, those all (at a glance) look ok for a (v1.0.3) "patch" release. Having that would help projects declare that they require
>= v1.0.3in their go.mod.cyphar commentedon Jul 3, 2020
@thaJeztah I think he's referring to the v1-to-v2 conversion text that's in #1040 right now (in other words, should we take the conversion text -- which is something runtimes are already implementing -- and leave the whole
unifiedthing for a separate release).@AkihiroSuda Since the text for the v1-to-v2 conversion is all gated by SHOULD and MAY, we could merge it now and change it in future releases without breaking backwards compatibility (since it's effectively just a recommendation or option for implementations, respectively). Do runc and crun already implement the semantics described (I haven't been following all of the cgroupv2 work in both projects)?
AkihiroSuda commentedon Jul 3, 2020
The v1-to-v2 conversion is already implemented, but the pure unified struct is not.
thaJeztah commentedon Jul 3, 2020
Thanks for clarifying, yes that sounds reasonable
giuseppe commentedon Jul 3, 2020
I'd prefer if it has not to wait so much longer, without #1040 the cgroup v2 support is limited to the same features present in cgroup v1
rhatdan commentedon Jul 8, 2020
@vbatts @mrunalp @AkihiroSuda @cyphar @crosbymichael Can we get this done?
28 remaining items
h-vetinari commentedon Dec 19, 2022
runtime-spec releases really are a sisyphean story...
There's a bunch of high-quality PRs that would suggest themselves for inclusion, but perhaps the current state of the repo should just be released to finally provide a new baseline, and then focus on getting those PRs merged for another release that's similarly just cut without a lot of ceremony?
It's a pity for those features, but it seems we're stuck in an infinite "just these couple more PRs before we release" cycle.
AkihiroSuda commentedon Jan 24, 2023
Let's move this forward
h-vetinari commentedon Mar 17, 2023
RC has been live for 6 weeks - is there anything in particular that's still necessary to happen for a release?
AkihiroSuda commentedon Mar 17, 2023
#1130 (comment)
AkihiroSuda commentedon Mar 28, 2023
Proposal for releasing v1.1.0-rc.2:
utam0k commentedon Mar 30, 2023
Can 1.1.0 include these at a minimum? I am not talking about the next rc.2.
AkihiroSuda commentedon May 22, 2023
Proposal for v1.1.0-rc.3
This should be the last RC for v1.1.0.
AkihiroSuda commentedon Jun 21, 2023
If there is no objection, I'd like to propose releasing v1.1 GA very soon.
utam0k commentedon Jun 22, 2023
👍
AkihiroSuda commentedon Jun 26, 2023
AkihiroSuda commentedon Jul 22, 2023
https://opencontainers.org/posts/blog/2023-07-21-oci-runtime-spec-v1-1/
https://github.com/opencontainers/runtime-spec/releases/tag/v1.1.0