Establish a release cadence for runc

[mrunalp]

We have a lot of new cgroups v2 related fixes that are going into runc, but we haven't cut any releases in a while. I think we should establish a release cadence, so that consumers can pick updates frequently without having to absorb a huge number of changes as they will have to with the next release or having to pin to arbitrary commits from the master branch in between releases.

I think we should make an attempt to identify issues we want to fix in a release, but not block a release entirely if one particular issue or feature doesn't make it in.

We can change the cadence depending on how many PRs are being merged. We may slow down again once cgroups v2 support stabilizes, but meanwhile, it will be good to have a more frequent cadence.

@opencontainers/runc-maintainers Thoughts?

I know we have conversations going on about the next rc and what the next release version should be, but I have created this issue to float the idea of a release cadence.

[kolyshkin]

I support this. Something like a monthly, bi-monthly, or a quarterly release schedule totally makes sense.

[cyphar]

I'm 👍 on a bi-monthly release schedule, and the complete removal of the voting system for releases. However, I'm not sure it's a good idea to do this before 1.0.0 -- purely because I don't want to end up with 6 more RCs. Once we get #2229 we can move as quickly to 1.0.0 as possible and then establish a proper release schedule.

[AkihiroSuda]

Let's make sure to support nesting (#2416) before rc11, otherwise downstream projects can't setup CI in a straightforward way

[mrunalp]

@cyphar I am a strong 👍 on removing the voting system for releases, but agree with the plan of getting 1.0.0 out first.
I have left review comments on #2229 and tested/reviewed #2416 as well. I would appreciate if others review #2229 as well so we can get to 1.0.0 and a bi-monthly release cadence. Thanks!

[kolyshkin]

I have some backward-incompatible changes in #2411 which should really go in before 1.0.0.

One other thing that needs to be done before 1.0.0 is reviewing the API (i.e. all the public identifiers) and moving the stuff that is not supposed to be used outside of runc into internal packages. I haven't even started on that so I assume this should take a few months, meaning we'll need another rc.

[cyphar]

One other thing that needs to be done before 1.0.0 is reviewing the API (i.e. all the public identifiers) and moving the stuff that is not supposed to be used outside of runc into internal packages. I haven't even started on that so I assume this should take a few months, meaning we'll need another rc.

Or we can simply state that the Go API is not something we support people using directly, and that only the CLI API follows SemVer. The fact that Go doesn't allow us to make the entire thing private is I think enough justification for us to be able to say that (even in "internal" packages, anybody could import one of those packages). If you want an actual internal package, I can easily post a PR that just moves everything to an internal package.

Practically speaking, we can work with projects like Kubernetes to move them away from using libcontainer directly (and we'll avoid breaking them), but I don't think giving API guarantees for the entirety of libcontainer is a good idea -- because (frankly) the vast majority of the API of libcontainer makes very little sense.

[dims]

@cyphar happy take on any ideas/suggestions to do on kubernetes side. echo-ing what @derekwaynecarr said before in #2364 (comment)

No issues with keeping up with the changes to the API either. the only sticking point from our side is needing/having specific tags to vendor in, instead of vendoring in a random SHA.

[cyphar]

This will be sorted out in post-1.0. I will include this in a set of governance updates that I'm working on for post-1.0.

[kolyshkin]

I was thinking about this today, looks like we can adopt something similar to what kubernetes is doing (https://github.com/kubernetes/website/blob/master/content/en/releases/patch-releases.md), in very short:

1. Do monthly (or bi-monthly) patch releases, (perhaps more frequent in the beginning of the 1.x series if there is a need).
2. Have a major release (1.1, 1.2) cut every 4 to 12 months (in our case this looks more like 12).
3. Have release branches (release-1.0, later release-1.1), backport the important stuff (security, critical/major fixes).
4. Support older release branches ^^^ for at least a year, maybe more for critical security fixes.

This should help vendors a lot (I'm speaking from a personal experience of backporting 0ca91f4 to 8 or so different runc versions), and does not look like a lot of burden.

[AkihiroSuda]

I'm not sure time-based release is good for us.
We can just release v1.1 when we have huge changes in the master branch.

I can't wait for 12 months for seccomp user notif (#2682) 😛

[cyphar]

I think we should have time-based releases, but I don't think we should follow as complicated a release model as Kubernetes has. We will probably have to have release branches, though it would be nice to minimise the amount of backporting necessary -- most downstreams of runc are used to using the latest release so we should probably not give people incentives to not follow that model going forward.

This is sort of like your suggestion @kolyshkin -- what about having a minor release every few months (let's say 3 months) with one or two rcs, and we backport security and bugfixes to the last two minor release branches? That way we only ever are maintaining two old branches. Patch releases for old versions should have very few fixes backported (so I don't expect you'd have more than a handful in most cases).

Supporting release branches for a year I think is a bit too much -- I would expect that most downstreams would prefer to update to runc 1.5.0 than to stay on runc 1.0.56 (since that is the model we've used to do date, and if we switch to supporting the other model, we've just made more work for ourselves -- when nobody is really asking us to do it).

(In order to get this to work we would also just drop the voting system for minor and patch releases -- those can just be done with a regular two-LGTM threshold. Doing releases is not that painful, and we should get into a habit of doing them more often -- a 12 month cycle for minor releases is way too long IMHO.)