search

opencontainers / runc

CLI tool for spawning and running containers according to the OCI specification
https://www.opencontainers.org/
Apache License 2.0
11.88k stars 2.11k forks source link

rc94 discussion (mid-April 2021?) #2790

Closed kolyshkin closed 3 years ago

kolyshkin commented 3 years ago

After releasing rc93, we are in feature freeze, i.e. only bug fixes¹ are accepted into rc94, which (hopefully) will be the last rc before the final 1.0 release.

Issues and PRs targeted for rc94 need to be added to 1.0.0-rc94 milestone

¹ I want to make an exception for CI improvements, as those do not directly affect the code, but might result in better quality/coverage/etc. Maybe also trivial features such as https://github.com/opencontainers/runc/pull/2789.

cyphar commented 3 years ago

Yeah, i'm fine with CI changes. Feature freeze doesn't include things like documentation and CI. Also depending on Docker's testing we might be able to skip rc94 entirely.

JonathonReinhart commented 3 years ago

Am I too late for #2826 to be considered for v1.0.0?

h-vetinari commented 3 years ago

Mid-march has arrived - there's still a fair amount of open PRs in the milestone. Biggest unknown seems to be #2797, which doesn't have a PR yet.

PS. June 4th is the 5th birthday of 1.0.0-rc1, would be fun if 1.0.0 could/would be released on that date 🙃

cyphar commented 3 years ago

I should have a PR for #2797 ready next week or so -- I was on vacation hence the lack of work on it. :wink:

EDIT: Ah, next week is hackweek. I will work on it the week after.

elldritch commented 3 years ago

Is there an ETA for the rc94 release? I'm particularly interested in https://github.com/opencontainers/runc/issues/2801#issuecomment-776190119 since I'm on Arch and Docker is just straight up broken for me until this patch is released. If the release is soon, I'll just wait for it, but if it's far off, I'm going to look at messing with my kernel parameters instead.

kolyshkin commented 3 years ago

Just talked to @cyphar -- it seems it makes sense to release rc94 before the cgroup v2 device changes he is working on are ready, as we already have a decent amount of fixes; that includes a fix for regression in rc93 (issues #2865, #2828, presumably fixed by PR #2871).

Let's try to merge the remaining PRs with the rc94 milestone and prepare a release.

cyphar commented 3 years ago

Yup, I can cook up a release with those fixes once they're merged.

AkihiroSuda commented 3 years ago

SGTM

haircommander commented 3 years ago

any opposition to adding https://github.com/opencontainers/runc/pull/2894 (fixes a regression between rc92 and rc93)

mrunalp commented 3 years ago

SGTM

cyphar commented 3 years ago

Only big thing remaining is #2896.

kolyshkin commented 3 years ago

I'd like to have https://github.com/opencontainers/runc/pull/2897 included as this fixes a real bug (albeit not a regression) and I'd rather have the fix being tested in rc94.

h-vetinari commented 3 years ago

It seems the usual** "just one more PR" also applies to this release, but the end seems to be in sight now - how about pushing this over the finish line?

** by "usual", I don't mean runc, but OSS 😅

tao12345666333 commented 3 years ago

SGTM Looking at milestone 1.0.0-rc94 , we will find that only #2906 is left now. Will we release rc94 after #2906 is completed?

AkihiroSuda commented 3 years ago

We want to fix the performance regression in rc93 before releasing rc94: https://github.com/opencontainers/runc/pull/2921

cyphar commented 3 years ago

Everything is merged. I will prepare a release PR on top of d279ebd97d8832020e2c6f50cc3a11d0499a4690.

kolyshkin commented 3 years ago

For the changelog, this is what I have based only on impact/changelog labels set:

Potentially breaking changes:

Bugfixes:

Improvements:

cpuguy83 commented 3 years ago

Callout for https://github.com/opencontainers/runc/issues/2928 ?

cyphar commented 3 years ago

It would be nice if we'd have a proper CHANGELOG.md so I didn't have to write one from scratch each time.

h-vetinari commented 3 years ago

It would be nice if we'd have a proper CHANGELOG.md so I didn't have to write one from scratch each time.

Ummmmm... #2368. I offered to do this (including backfilling for a few releases using a to-be-agreed format), but the appetite was very low.

cyphar commented 3 years ago

Yeah I remember the issue, the problem was that back-filling the changelog with prettified git log messages isn't quite ideal. Back-filling it with the actual release notes is probably more useful to be honest. But I don't even think we need to backfill it, we could just start a new changelog from scratch with the next release and add stuff with each PR.

h-vetinari commented 3 years ago

[...] back-filling the changelog with prettified git log messages isn't quite ideal. Back-filling it with the actual release notes is probably more useful to be honest.

That was the only starting point; could have been brought into better shape (e.g. the format in the linked comment) during the PR, and including previous release notes would be trivial.

kolyshkin commented 3 years ago

It would be nice if we'd have a proper CHANGELOG.md so I didn't have to write one from scratch each time.

My proposal is to

  1. Have impact/changelog label for every PR that is worth mentioning (bug fix, notable improvement, new feature, potentially breaking change etc).
  2. Have a "Changelog entry" field in such PRs.
  3. collect those entries before the release.

This is sort of what I did. Was not perfect but AFAICS it works.

tao12345666333 commented 3 years ago

I agree with @kolyshkin ‘s proposal. We can reach an agreement during the PR merger without having to count again afterwards.

cyphar commented 3 years ago

v1.0.0-rc94 has been released. https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc94

h-vetinari commented 3 years ago

Very happy to see - congrats everyone! 🥳😊

Just slightly surprised that there was no wording about the imminent 1.0.0 release? rc93 had this to say:

This is the last feature-rich RC release and we are in a feature-freeze until 1.0. 1.0.0~rc94 will be released in a few weeks with minimal bug fixes only, and 1.0.0 will be released soon afterwards.

... so I would have expected something along the lines of "If no critical regressions are found in the next X weeks, rc94 will be released as runc 1.0.0 on Y (allowing for trivial bugfixes & CI improvements)."

(on a less serious note, let me reiterate the suggestion that Y should be the 3th of June for celebratory reasons 🙃)

commit 04f275d4601ca7e5ff9460cec7f65e8dd15443ec (tag: v1.0.0-rc1)
Author: Michael Crosby <crosbymichael@gmail.com>
Date:   Fri Jun 3 15:25:47 2016 -0700

    Update runc version to 1.0.0-rc1

    Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
cyphar commented 3 years ago

I think I've decided that saying it will not have any new features is just jinxing it (I've been saying it for almost 2 years now I think).

h-vetinari commented 3 years ago

I think I've decided that saying it will not have any new features is just jinxing it (I've been saying it for almost 2 years now I think).

It's been a long road indeed, yet before there was always some big thing (spec-compliance, hooks, cgroups v2, etc.) for which all other work could not reasonably be blocked. Now would IMO be an excellent opportunity to nail this down and not allow further feature creep.

cyphar commented 3 years ago

@h-vetinari The reason I didn't put that note is because I knew we would be doing another release today to fix the CVE. There are only two PRs in the 1.0.0 milestone, we will do a release once they are merged (barring any other critical fixes).

h-vetinari commented 3 years ago

The reason I didn't put that note is because I knew we would be doing another release today to fix the CVE

Makes complete sense, but I couldn't know that 😅

There are only two PRs in the 1.0.0 milestone, we will do a release once they are merged

Very happy to hear it, amazing to see this (leg of the) journey come to an end! 😊