-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Establish a release cadence for runc #2435
Comments
I support this. Something like a monthly, bi-monthly, or a quarterly release schedule totally makes sense. |
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 |
Let's make sure to support nesting (#2416) before rc11, otherwise downstream projects can't setup CI in a straightforward way |
@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 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 |
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 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 |
@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. |
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. |
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:
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. |
I'm not sure time-based release is good for us. I can't wait for 12 months for seccomp user notif (#2682) 😛 |
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.) |
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 Is |
The jump from 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. |
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. |
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 |
Better late than never, I think this is now fixed by PR #4557 (see RELEASES.md) |
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.
The text was updated successfully, but these errors were encountered: