Change of support policy: one release track, on-demand releases

[tsaarni]

What do you want the project to decide?

According to current support policy, Contour should release quarterly and maintain support for three release tracks with regular patch updates https://projectcontour.io/resources/support/. However, this policy has not been followed recently due to limited resources.

I propose that we move to support a single release track at a time, with new releases made on-demand rather than following a fixed schedule.

[skriss]

From my perspective this makes sense, as I am personally unable to commit to the three release tracks + patch releases at this time.

cc @sunjayBhatia

[sunjayBhatia]

I think for our internal requirements we'll want to keep a range of versions to cover a wider range of k8s version compatibility, so I'll have to think a bit about how that will work, but I agree with the overall sentiment, we have not cut a minor release in a while partly because it feels expensive to do so! and our current milestone is not quite exhausted

[tsaarni]

The support policy with three release tracks, combined with the slow release cadence (non-calendar-based), has resulted in extended support for older maintenance tracks. Even the latest release is compiled with Go version that already passed end-of-life.

It seems to me that the way how Go language has evolved, version bumps now have quite big cascading effects. For example, just to compile our latest release track release-1.30 with new Go compiler I needed to do this https://github.com/projectcontour/contour/pull/6987. It ended up pulling client-go v0.32.2 which is still compatible with Kubernetes versions 1.28 through 1.30 which we announced originally for this release track. I did not try if release-1.30 runs on Kubernetes 1.27 (oldest indicated in release-1.28). Maybe it would work even after https://github.com/projectcontour/contour/pull/6987?

Curiously, just one week from now, none of these Kubernetes versions we test release-1.30 against are supported by upstream Kubernetes, which could be a problem as well.

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack