From b73e8c28fea6eff93e3c34ab937b2bec0cb58f52 Mon Sep 17 00:00:00 2001 From: Sam Barker Date: Fri, 19 Jun 2026 15:37:55 +1200 Subject: [PATCH 1/3] Outline the mechanism for getting a maintenance release Signed-off-by: Sam Barker --- release-schedule.markdown | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/release-schedule.markdown b/release-schedule.markdown index 5b12d72..31a66d6 100644 --- a/release-schedule.markdown +++ b/release-schedule.markdown @@ -42,3 +42,31 @@ permalink: /release-schedule/ + +
+
+
+

Backports, CVEs, and respins, oh my!

+

Kroxylicious is a community endeavour: we maintain one branch, main, and make releases from it. + We always recommend running the latest release.

+

We recognise this doesn't work for everyone. The community can get fixes into older releases — with a little help from a friend.

+

A note on respins: a CVE in a base image alone is not a reason to cut a maintenance release — rebuild your container image instead. + Maintenance releases are for vulnerabilities in Kroxylicious code or its runtime dependencies.

+ +

How to get a maintenance release

+
    +
  1. Start a conversation — any community member, committer, project manager, or otherwise needs to drop a note to kroxylicious-dev@googlegroups.com describing the version you need and the fixes required. + This is a discussion, not a demand: you'll need to convince a committer that a maintenance release makes sense.
    2. +
  2. A committer creates the release branch — if a committer agrees, they will create a release/X.Y branch. + Community members cannot create release branches directly; this step requires a committer.
    3. +
  3. The community does the work — cherry-picks from main are ideal, but not always practical. + Were main ever to move to a new major version of a core dependency, an older release on the previous version would need changes adapted rather than simply cherry-picked. + The contributor proposing the backport is responsible for that adaptation.
    4. +
  4. Agree scope — before cutting the maintenance release, the committer should call for lazy consensus on the mailing list: share what will be included and allow a reasonable window for objections. + There's no value in running the release machinery for every individual change; batching is preferred. + For a highly exploitable CVE the committers may agree to shorten or waive the consensus window.
    5. +
  5. A committer cuts the release — once consensus is reached, lazy style, on the branch content, a committer will cut the release.
    6. +
+
+
+
From 3954337ad6005456e59b11584e24e40142b90aa0 Mon Sep 17 00:00:00 2001 From: Sam Barker Date: Fri, 19 Jun 2026 15:51:48 +1200 Subject: [PATCH 2/3] tweak who initiates the process Signed-off-by: Sam Barker --- release-schedule.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release-schedule.markdown b/release-schedule.markdown index 31a66d6..abc40fd 100644 --- a/release-schedule.markdown +++ b/release-schedule.markdown @@ -55,7 +55,7 @@ permalink: /release-schedule/

How to get a maintenance release

    -
  1. Start a conversation — any community member, committer, project manager, or otherwise needs to drop a note to kroxylicious-dev@googlegroups.com describing the version you need and the fixes required. +
  2. Start a conversation — anyone in the community, including committers and project managers, needs to drop a note to kroxylicious-dev@googlegroups.com describing the version you need and the fixes required. This is a discussion, not a demand: you'll need to convince a committer that a maintenance release makes sense.
  3. A committer creates the release branch — if a committer agrees, they will create a release/X.Y branch. Community members cannot create release branches directly; this step requires a committer.
    4. From 8ba3e883b181f165d0009908dd01779c7bc9f083 Mon Sep 17 00:00:00 2001 From: Sam Barker Date: Fri, 19 Jun 2026 16:14:50 +1200 Subject: [PATCH 3/3] Redirect people looking to raise CVEs to the disclosure policy Signed-off-by: Sam Barker --- release-schedule.markdown | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/release-schedule.markdown b/release-schedule.markdown index abc40fd..894aa47 100644 --- a/release-schedule.markdown +++ b/release-schedule.markdown @@ -47,9 +47,13 @@ permalink: /release-schedule/

    Backports, CVEs, and respins, oh my!

    +

    Kroxylicious is a community endeavour: we maintain one branch, main, and make releases from it. We always recommend running the latest release.

    We recognise this doesn't work for everyone. The community can get fixes into older releases — with a little help from a friend.

    +

    A note on respins: a CVE in a base image alone is not a reason to cut a maintenance release — rebuild your container image instead. Maintenance releases are for vulnerabilities in Kroxylicious code or its runtime dependencies.