Runc: 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 :+1: 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 (https://github.com/opencontainers/runc/pull/2416) before rc11, otherwise downstream projects can't setup CI in a straightforward way

[mrunalp]

@cyphar I am a strong :+1: 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 https://github.com/opencontainers/runc/pull/2364#issuecomment-628089756

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.