RELEASES: add formal release policy for runc

[cyphar]

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]

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

• Mrunal Patel [email protected] (@mrunalp)
• Aleksa Sarai [email protected] (@cyphar)
• Akihiro Suda [email protected] (@AkihiroSuda)
• Kir Kolyshkin [email protected] (@kolyshkin)
• Sebastiaan van Stijn [email protected] (@thaJeztah)
• Li Fu Bang [email protected] (@lifubang)
• Rodrigo Campos [email protected] (@rata)

[dims]

thanks for writing this down @cyphar !

[kolyshkin]

LGTM

[cyphar]

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.

[rata]

LGTM, thanks!

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

[thaJeztah]

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

[thaJeztah]

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

[thaJeztah]

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)

[cyphar]

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.

[thaJeztah]

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.

[cyphar]

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