The Art of Kubernetes Versions: A Behind-the-Scenes Look at the Release Group

Introduction

The Release Special Interest Group (SIG Release) is the heart of Kubernetes when it comes to releasing new features and bug fixes every four months. Have you ever wondered how such a large project like Kubernetes manages its schedule so efficiently? In this article, we take a look at the processes within the release team and how you can participate.

What Specifically Changes for Developers/DevOps Teams?

SIG Release plays a crucial role in the development and evolution of Kubernetes. The main goal of this group is to manage the release process of new Kubernetes versions. This occurs in a regular cycle, typically every three to four months. During this cycle, the Kubernetes release team works closely with other SIGs and contributors to ensure a smooth and well-coordinated release. This includes planning the release schedule, setting deadlines for code freezes and testing phases, and creating release artifacts such as binaries, documentation, and release notes.

It’s important to know that there are two subprojects within SIG Release – Release Engineering and Release Team.

Practical Examples or Use Cases

Below are the steps of the typical release process for a new Kubernetes version:

Onboarding the Release Team: At the beginning, a release team is formed, consisting of volunteers from the Kubernetes community who are responsible for various components of the new version. This usually happens before the previous version is completed. An example of the team composition can be found here.
Initial Phase: In the first weeks of each release cycle, SIG Release closely monitors the progress of new features and improvements documented in Kubernetes Enhancement Proposals (KEPs). Many of these features go through the Alpha, Beta, and finally stability phases.
Feature Maturation Phase: In this phase, several alpha releases are created to gather feedback from the community. This is followed by beta releases, where the focus is on fixing bugs. User feedback is crucial here, so it may sometimes be necessary to create an additional beta release to address issues that have arisen. After this phase, a Release Candidate (RC) is created before the final version is released.

The work within SIG Release is not only important for developers but also for DevOps teams who want to ensure their applications can smoothly migrate to the latest Kubernetes versions.

If you want to learn more about the work of SIG Release or get involved, don’t hesitate to join the community. ayedo is proud to support the development and implementation of such valuable initiatives as a Kubernetes partner!

Source: Kubernetes Blog