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.)

[akhilerm]

Was there a conclusion on the release cadence for runc?

Also would like to know the accepted support interval. Going through some issues, found that there will be no more releases in the v1.1.x series and will be moving to the next major (v1.2.0) release. Will there be support for the v1.1.x releases ?

Is v1.2.0 planned to be backward compatible with the latest version in v1.1.x?

[cyphar]

The jump from v1.1.x to v1.2.0 is a minor release, not a major release. As per SemVer, it will be backwards compatible (but will contain new features).

We didn't come to a conclusion for the right release cadence, though I still stand by the argument that doing minor releases every 3-6 months is probably the best way to ensure we release features regularly.

[kolyshkin]

OK, now we're past v1.2.0 release 😅 , let's establish a time-based release cadence.

I propose we try very hard to release 1.3.0 in April, i.e. six months from now.

[h-vetinari]

try very hard to release [...] six months from now.

Sounds like a great idea IMO! Once upon a time I suggested a similar timeframe, but what I think is crucial to make that happen is to create a release branch and start winding down well before that deadline.

For example, the release branch could be created 4, 6 or 8 weeks before the target date (depending on how stable main is perceived to be), then release rc1 from that branch already, and subsequently only backport crucial fixes, while feature work can continue on main.

[kolyshkin]

Better late than never, I think this is now fixed by PR #4557 (see RELEASES.md)