Skip to content
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

RELEASES: add formal release policy for runc #4557

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Dec 17, 2024

Historically, our release cadence and support policy has been quite
ad-hoc, which has caused some strife and is not really becoming of a
project as widely used as ours. So, in an attempt to make our releases
more regular and to provide more guidance on our backport policy, add a
document outlining our policy.

Signed-off-by: Aleksa Sarai [email protected]

@cyphar cyphar added this to the 1.3.0 milestone Dec 17, 2024
@cyphar
Copy link
Member Author

cyphar commented Dec 17, 2024

As this is more of a governance-related discussion, it would be nice to hear the opinions of (and once we've agreed on a potential policy, get approvals from) from two-thirds of maintainers (5):

@cyphar cyphar force-pushed the release-policy branch 2 times, most recently from 6af6e7f to 58969b8 Compare December 17, 2024 04:31
RELEASES.md Outdated Show resolved Hide resolved
RELEASES.md Outdated Show resolved Hide resolved
@cyphar cyphar force-pushed the release-policy branch 5 times, most recently from 2ac5ef7 to 2973f35 Compare December 17, 2024 13:46
@dims
Copy link
Contributor

dims commented Dec 17, 2024

thanks for writing this down @cyphar !

Copy link
Contributor

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

RELEASES.md Show resolved Hide resolved
@cyphar
Copy link
Member Author

cyphar commented Dec 18, 2024

We've hit the required LGTM threshold, but we can hold off on merging for a bit, to see if @mrunalp @thaJeztah or @rata had any comments.

EDIT: Oops, I miscounted the number of maintainers. We needed one more LGTM.

Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

Sorry, I've been out for a long time and I'll still be away until mid January or so.

Historically, our release cadence and support policy has been quite
ad-hoc, which has caused some strife and is not really becoming of a
project as widely used as ours. So, in an attempt to make our releases
more regular and to provide more guidance on our backport policy, add a
document outlining our policy.

Signed-off-by: Aleksa Sarai <[email protected]>
Comment on lines +11 to +12
runc uses [Semantic Versioning][semver] for releases. However, our
compatibility policy only applies to the runc binary. We will make a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My pet-peeve with go modules having unilaterally claimed ownership of GitHub tags, and now interpreting them as SemVer for the Go API (whereas the intent was for binary releases) 😞

Comment on lines +14 to +15
Go packages prefixed with `github.com/opencontainers/runc`, but we do not
formally guarantee that API compatibility will be preserved.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to mention that we will try (best effort) include potentially breaking changes in the Go API as part of the release notes and users should familiarise themselves with the changes in the release notes before updating?

We could also call out (but maybe we do somewhere) that (due to SemVer compatibility of the binary), updates of the runc binary may not require updating of runc library (go module) (this is mostly me having bad memories of containerd originally coupling those versions, resulting in go module updates for no practical reason).

FWIW, I stumbled on this project, some time ago that may help checking for changes in the Go API (it may be limited, but could help as a tool in our tool belt) https://github.com/joelanford/go-apidiff

Comment on lines +53 to +60
| 200X-03-12 | `1.3.0-rc.2` | |
| 200X-03-25 | `1.3.0-rc.3` | |
| 200X-04-30 | `1.3.0` | `1.3` release published. |
| 200X-05-10 | `1.3.1` | |
| 200X-06-21 | `1.3.2` | |
| 200X-06-25 | `1.3.3` | |
| 200X-07-02 | `1.3.4` | |
| 200X-08-28 | `1.4.0-rc.1` | `release-1.4` branch created, feature freeze. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the only thing I'm wondering here with the example is that SemVer determines if a release will be major, minor, or patch; there may be roadmap items, but it's not a given that new features are to be added in any timeframe; i.e., with some parts of the container ecosystem stabilising, it's possible that we go 6 months without new features added.

That means we can decide on a "check in" schedule to see;

  • what changes were merged (fixes, features)
  • what changes have been accepted and are expected to land in the given timeframe
  • depending on the accepted features (i.e., a contributing party may have proposed a feature that's accepted, and the contributing party may have communicated a desired (and realistic) timeframe, such a feature could be marked a "blocker" for the release

With the above taken into account, I would consider

  • feature releases having to be planned (proposed feature is accepted -> progress is checked -> preliminary date is set for the feature release)
  • non-feature releases (patch releases) could have a (say) monthly cadence if any fixes were merged
  • security / critical fixes to be an exception (to be announced ahead of time unless zero-day)

Copy link
Member Author

@cyphar cyphar Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally prefer that we end up with a minor release without any new features rather than a delayed minor release because we didn't have a strict enough deadline.

IMHO even if a minor release doesn't have many (or any) new features that's fine. SemVer says that minor bumps MUST be done for features, but it doesn't say they MUST NOT be done in absence of features (the wording of s6 sounds like it strongly disagrees with this point but s7 says that we can do minor releases in case of "It MAY be incremented if substantial new functionality or improvements are introduced within the private code" which is fairly carte blanche). And while it is a minor thing, doing minor releases means that we shorten the lifespan of release branches, which makes backports less painful.

IMHO we've already tried to do the "we'll release once we have a new feature that deserves a release" approach and that doesn't seem to work for us (to be fair, we weren't strict enough about deadlines but I think a deadline decided that way is going to end up being somewhat loose). Having an automated deadline decided long in advance without needing to think about IMHO would make it easier for us and our users to plan around (not to mention it will make revert decisions much easier). It also means we only need to agree on this timeline once for the life of the project, rather than getting agreement for each minor release.

Comment on lines +86 to +89
* Once `latest` is released, new features will no longer be merged into
`latest` and only bug and security fixes will be backported, though we will
be fairly liberal with what kinds of bugs will considered candidates for
backporting.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is already covered by describing that we follow SemVer for releases; Once a minor (i.e. "feature" release) is done, its set of features is frozen; any new feature requires updating the minor version.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but given that we haven't always followed this in the past, it might be nice to make this explicit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants