Release Changes: Overview

[kflynn]

There's a Google doc with a bunch of changes being proposed for the next Gateway API release. Some of these seem fairly straightforward (e.g. there are already folks working on getting GEPs into Provisional, which is great!). Some seem less straightforward.

Overview of changes

1. We'll choose a date for standard-channel releases, but we won't choose the content.

   • The date should not slip: the content is allowed to be flexible.
   • Whatever content is ready to go at the date will ship; what content isn't will wait for the next release.
   • Ideally, we also pick the release number at the point its content is known.

2. To get a new item into the experimental channel, you need to get a Who/What/Why GEP merged as provisional, and you need to line up three implementations (two for mesh) to sponsor it by committing to implement it as an experimental feature.

   • The idea of having the provisional GEP first is to have better information about what the feature is before we agree to take it into experimental.
   • The idea of lining up sponsors is a shift left of existing requirements: you'll need implementations to go to standard, and in practice you need implementations to test things anyway, so let's just line sponsors up first.

3. Once an item is accepted into the experimental channel, it will be automatically removed if it doesn't make any significant progress in six months.

   • "Significant" is deliberately vague. This is meant to be an easy bar to get over: if you're working on a thing, it won't get dropped. If no one is working on it, it'll fall out and clear bandwidth for something else.
   • There's no requirement that the original author be the one driving "progress". If you have to walk away from Gateway API for awhile, handing off to someone else is actively encouraged.

4. We'll start doing monthly releases, tagged monthly-$year-$month (e.g. monthly-2025-10), of the experimental channel.

   • The point here is to make it faster to iterate in experimental.
   • These will be snapshots of main. If you find a bug in a monthly, the solution is to upgrade to a newer monthly -- we won't do backports of fixes.
   • These deliberately don't use SemVer release numbers, because breaking changes are always allowed between monthlies.

5. We'll use validating admission policies (VAP) to protect things.

   • An "upgrade VAP" will prevent applying experimental-channel CRDs over standard-channel CRDs.
     • If you really want to do this, you'll have to remove this VAP.
   • A "guardrails VAP" will prevent setting any experimental fields of a resource unless an annotation is also present.
     • Without the annotation, you get standard-channel functionality.

Sequencing

Changes 1, 2, and 3 are mostly just a matter of deciding to do them. With the exception of choosing the release number at the end, I think we mostly have consensus here.

• Change 1: irrespective of what we decide about release numbering, choosing to allow content to slip rather than allowing the date to slip doesn't require anything other than documentation.
• Change 2 requires adding a Sponsors section to the GEP template and a date field to the metadata.yaml.
• Change 3 would benefit from automation, but can be done by hand at first.

Change 4 requires release-engineering work plus the VAPs from change 5. This is extremely unlikely to happen before KubeCon in November.

What's Next?

Please reread the Release Changes doc since many of its comments are believed to be addressed. If you have a comment that is not addressed, please transfer it here (or, if you like, start a new discussion for it and drop the new discussion's link here). We'll try to reach what consensus we can asynchronously before, hopefully, concluding the discussion in the Gateway API meeting on 21 October.

[youngnick]

Agreed on the changes and the sequencing, broadly.

I think that Change 2 does require adding a Sponsors section to the GEP template, but we could maybe add more than one field to the metadata.yaml schema - maybe a lastUpdated and a created date, or some similar thing, that will let us collect data on timings in the future.

[snorwin]

I fully agree with changes 1–3. However, I have some reservations, particularly about removing the experimental channel from the release cycle and transforming it into monthly snapshots.

As mentioned in the comments of the Release Changes doc I’m wondering whether implementations would realistically be able to adopt and implement monthly experimental releases. IMO, there should be a clear commitment from at least five implementers to ensure that the intended goal of faster and broader feedback can actually be achieved.

[mikemorris]

whether implementations would realistically be able to adopt and implement monthly experimental releases

TBH I wouldn't expect implementations to always release right after the latest experimental monthly with support, it's more like "whenever an implementation releases, it becomes easier to support newer experimental features if desired [because they have already been released], rather than waiting several months or needing to align implementation release schedules with Gateway API releases (although that may still be desirable around the standard channel schedule).

As a concrete example, Istio maintains a quarterly release schedule, and having monthly Gateway API releases could allow introducing support for new experimental features or changes in every release (assuming maintainer bandwidth to actually implement support) potentially dropping the "wait time" for a new experimental feature merged just after a Gateway API standard release from 5+ months to under 2 months.

[snorwin]

That’s a fair point, I hadn’t considered it from that perspective before.

The second concern is whether we can make these snapshots stable enough, and whether there are actual end users willing to install snapshot releases on their cluster. In our case, the most valuable feedback comes from users who are actively using the experimental channel.

[shaneutt]

Strongly aligned on strengthening our "motivation-first proposals" philosophy.

Strongly aligned with making it easier, quicker and more iterative to work on Experimental GEPs, and Experimental should absolutely stay true to its namesake.

As we make Experimental easier and faster, we need to make Standard slower and more deliberate.