Hi there,
Recently, I was assigned an task in the Kubernetes community to write a Spotlight Blog on the SIG Release. Spotlight Blog is a blog that articulates the struggles and sheds a spotlight on a specific SIG around its role and shared struggles in the Kubernetes community. I’m glad to interview the Leads and Chairs of the SIG Release.
Before the blog goes out public, I’d like to discuss some important answers to the questions that literally surprised me.
- What is the typical release process for a new version of Kubernetes, from initial planning to the final release look like? Are there any smooth methodologies and tools that you use to ensure smooth release?
-
The release process for a new version is a well-structured and community-driven effort. Although we don’t use any specific famous methodologies, we follow a calendar and series of steps to keep things organised. It looks something like this:
We start with the formation of a Release Team, which includes volunteers from the community responsible for managing different components of the release. This is typically done before the previous release is about to wrap up. Once the team is formed, new members are onboarded while the Release Team Lead and the Branch Manager propose a calendar for the usual deliverables.
During the first few weeks of the release cycle, new features and enhancements proposed through Kubernetes Enhancement Proposals (KEPs) are tracked. Not all of them are brand new though, since they typically start in alpha, then graduate to beta, and eventually considered stable. This process spans across several release versions cycles.
A few weeks before the release, we implement a Code Freeze, where no new features are allowed after this point. This allows the focus to shift towards testing and stabilisation.
We usually cut a couple of Alpha releases containing new features in an experimental state to gather feedback from the community, followed by a couple of Beta releases, where features are more stable, and the focus is on fixing bugs. Feedback from users is critical at this stage, to the point where sometimes we need to cut an additional Beta release to address bugs or other concerns that may arise during this phase. Once this is cleared, we cut a RC (release candidate) before the actual release. Throughout the cycle, efforts are made to update and improve documentation, including release notes and user guides, a process that, in my opinion, deserves its own post.
Additionally to the main release, we keep cutting monthly patches of old, officially supported versions of Kubernetes, so you could say that the lifecycle of a Kubernetes version extends for several months afterwards.
- As a new contributor, what should be my ideal path to get involved with the sig release? In a community where everyone is busy with their own tasks, how can I find the right set of tasks that I can accomplish to contribute effectively to the sig release?
-
Get familiar with the code, including how features are managed, the release calendar, and the overall structure of the team. Join the Kubernetes community communication channels, such as Slack (#sig-release), where we are particularly active.
-
We also hold weekly meetings, which are open to the community. Participating in these meetings is a great way to learn about ongoing and future projects that you might find relevant for your skillset and interests.
-
SIG Release is a self-serving team, meaning that we write our own tools to be able to ship releases. We collaborate a lot with other SIGs, such as SIG Infra, but all the tools that we use need to be tailor-made for our massive technical needs, while reducing costs. This means that we are constantly looking for volunteers who’d like to help with different types of projects, beyond “just” cutting a release.
-
The combined skillset for our current projects includes Go, Kubernetes internals, linux packaging, supply chain security, technical writing, and generals of how to maintain an OSS project, but it’s always transforming
Only this? Well this is just the tip of Iceberg. I’d love to share the blog with the community when it finally gets published. There are several good answers and interesting theories on how Kubernetes Release Team manages the release process so efficiently. We all can learn a lot of things from the Kubernetes Release Team.
Furthermore, I’m happy to share with y’all that I’ll be working under the Kubernetes Release Engineering Team as a part of LFX Mentee, working on building Library and CLI tool for the Release Team this fall.
Let me know your thoughts over this post, what questions you’d like to ask the Release Team of Kubernetes.
