Skip to content

Change the cluster support policy to 3 month after release

Release notes

Problem to solve

As a GitLab user, I want to have recent Kubernetes versions supported continuously, so I can build the integrations on top of GitLab features.

Today, the list of supported Kubernetes clusters is updated on an ad-hoc basis. As for maintenance work, it is typically hard to prioritize despite our best interests.

Proposal

We should change the method of support to targeting adding support to new cluster versions 3 months after the release.

Thus if a release comes out during milestone work X, we target to add support in milestone %X+3 latest. This allows us to have a stricter schedule around testing a new Kubernetes version, like having it tested during milestone %X+1. If maintenance work is needed, schedule it for milestones %X+2 and %X+3.

At the same time, we should continuously support 3 versions of Kubernetes.

An example sheet how this would have played out is shown in https://docs.google.com/spreadsheets/d/1w0eE5hcH3UDjNgOn6tZFAkeQb5wy9Q09kLePfygtx1Y/edit#gid=1497100727

Timing

When to change the policy? Once we catch up. Likely once we add Kubernetes version 1.24 support.

Questions

  • When to remove support for deprecated APIs?
    • If there is an alternative (like beta -> GA API): At the earliest release when we drop support for a version that does not support the recommended alternative. The example sheet shows that autoscaling/v2beta1 got deprecated in favor of autoscaling/v2 in v1.23. We would drop support for autoscaling/v2beta1 deprecated when on 2022-11-22 when we remove support for version 1.22.
    • If there is no alternative: At the time when we drop support for the last version that supported the deprecated API.

References

Edited by Viktor Nagy (GitLab)