그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그

  11 minute read  

Releases, Features, Hotfixes

This document describes how to contribute features or hotfixes, and how new Gardener releases are usually scheduled, validated, etc.

Releases

The @gardener-maintainers are trying to provide a new release roughly every other week (depending on their capacity and the stability/robustness of the master branch).

Hotfixes are usually maintained for the latest three minor releases, though, there are no fixed release dates.

Release Responsible Plan

VersionWeek NoBegin Validation PhaseDue DateRelease Responsible
v1.101Week 31-32July 29, 2024August 11, 2024@rfranzke
v1.102Week 33-34August 12, 2024August 25, 2024@plkokanov
v1.103Week 35-36August 26, 2024September 8, 2024@oliver-goetz
v1.104Week 37-38September 9, 2024September 22, 2024@ialidzhikov
v1.105Week 39-40September 23, 2024October 6, 2024@acumino
v1.106Week 41-42October 7, 2024October 20, 2024@timuthy
v1.107Week 43-44October 21, 2024November 3, 2024@LucaBernstein
v1.108Week 45-46November 4, 2024November 17, 2024@shafeeqes
v1.109Week 47-48November 18, 2024December 1, 2024@ary1992
v1.110Week 48-49December 2, 2024December 15, 2024@ScheererJ
v1.111Week 50-51December 30, 2024January 26, 2025@oliver-goetz
v1.112Week 01-04January 27, 2025February 9, 2025@tobschli
v1.113Week 05-06February 10, 2025February 23, 2025@plkokanov
v1.114Week 07-08February 24, 2025March 9, 2025@rfranzke
v1.115Week 09-10March 10, 2025March 23, 2025@ialidzhikov

Apart from the release of the next version, the release responsible is also taking care of potential hotfix releases of the last three minor versions. The release responsible is the main contact person for coordinating new feature PRs for the next minor versions or cherry-pick PRs for the last three minor versions.

Click to expand the archived release responsible associations!
VersionWeek NoBegin Validation PhaseDue DateRelease Responsible
v1.17Week 07-08February 15, 2021February 28, 2021@rfranzke
v1.18Week 09-10March 1, 2021March 14, 2021@danielfoehrKn
v1.19Week 11-12March 15, 2021March 28, 2021@timebertt
v1.20Week 13-14March 29, 2021April 11, 2021@vpnachev
v1.21Week 15-16April 12, 2021April 25, 2021@timuthy
v1.22Week 17-18April 26, 2021May 9, 2021@BeckerMax
v1.23Week 19-20May 10, 2021May 23, 2021@ialidzhikov
v1.24Week 21-22May 24, 2021June 5, 2021@stoyanr
v1.25Week 23-24June 7, 2021June 20, 2021@rfranzke
v1.26Week 25-26June 21, 2021July 4, 2021@danielfoehrKn
v1.27Week 27-28July 5, 2021July 18, 2021@timebertt
v1.28Week 29-30July 19, 2021August 1, 2021@ialidzhikov
v1.29Week 31-32August 2, 2021August 15, 2021@timuthy
v1.30Week 33-34August 16, 2021August 29, 2021@BeckerMax
v1.31Week 35-36August 30, 2021September 12, 2021@stoyanr
v1.32Week 37-38September 13, 2021September 26, 2021@vpnachev
v1.33Week 39-40September 27, 2021October 10, 2021@voelzmo
v1.34Week 41-42October 11, 2021October 24, 2021@plkokanov
v1.35Week 43-44October 25, 2021November 7, 2021@kris94
v1.36Week 45-46November 8, 2021November 21, 2021@timebertt
v1.37Week 47-48November 22, 2021December 5, 2021@danielfoehrKn
v1.38Week 49-50December 6, 2021December 19, 2021@rfranzke
v1.39Week 01-04January 3, 2022January 30, 2022@ialidzhikov, @timuthy
v1.40Week 05-06January 31, 2022February 13, 2022@BeckerMax
v1.41Week 07-08February 14, 2022February 27, 2022@plkokanov
v1.42Week 09-10February 28, 2022March 13, 2022@kris94
v1.43Week 11-12March 14, 2022March 27, 2022@rfranzke
v1.44Week 13-14March 28, 2022April 10, 2022@timebertt
v1.45Week 15-16April 11, 2022April 24, 2022@acumino
v1.46Week 17-18April 25, 2022May 8, 2022@ialidzhikov
v1.47Week 19-20May 9, 2022May 22, 2022@shafeeqes
v1.48Week 21-22May 23, 2022June 5, 2022@ary1992
v1.49Week 23-24June 6, 2022June 19, 2022@plkokanov
v1.50Week 25-26June 20, 2022July 3, 2022@rfranzke
v1.51Week 27-28July 4, 2022July 17, 2022@timebertt
v1.52Week 29-30July 18, 2022July 31, 2022@acumino
v1.53Week 31-32August 1, 2022August 14, 2022@kris94
v1.54Week 33-34August 15, 2022August 28, 2022@ialidzhikov
v1.55Week 35-36August 29, 2022September 11, 2022@oliver-goetz
v1.56Week 37-38September 12, 2022September 25, 2022@shafeeqes
v1.57Week 39-40September 26, 2022October 9, 2022@ary1992
v1.58Week 41-42October 10, 2022October 23, 2022@plkokanov
v1.59Week 43-44October 24, 2022November 6, 2022@rfranzke
v1.60Week 45-46November 7, 2022November 20, 2022@acumino
v1.61Week 47-48November 21, 2022December 4, 2022@ialidzhikov
v1.62Week 49-50December 5, 2022December 18, 2022@oliver-goetz
v1.63Week 01-04January 2, 2023January 29, 2023@shafeeqes
v1.64Week 05-06January 30, 2023February 12, 2023@ary1992
v1.65Week 07-08February 13, 2023February 26, 2023@timuthy
v1.66Week 09-10February 27, 2023March 12, 2023@plkokanov
v1.67Week 11-12March 13, 2023March 26, 2023@rfranzke
v1.68Week 13-14March 27, 2023April 9, 2023@acumino
v1.69Week 15-16April 10, 2023April 23, 2023@oliver-goetz
v1.70Week 17-18April 24, 2023May 7, 2023@ialidzhikov
v1.71Week 19-20May 8, 2023May 21, 2023@shafeeqes
v1.72Week 21-22May 22, 2023June 4, 2023@ary1992
v1.73Week 23-24June 5, 2023June 18, 2023@timuthy
v1.74Week 25-26June 19, 2023July 2, 2023@oliver-goetz
v1.75Week 27-28July 3, 2023July 16, 2023@rfranzke
v1.76Week 29-30July 17, 2023July 30, 2023@plkokanov
v1.77Week 31-32July 31, 2023August 13, 2023@ialidzhikov
v1.78Week 33-34August 14, 2023August 27, 2023@acumino
v1.79Week 35-36August 28, 2023September 10, 2023@shafeeqes
v1.80Week 37-38September 11, 2023September 24, 2023@ScheererJ
v1.81Week 39-40September 25, 2023October 8, 2023@ary1992
v1.82Week 41-42October 9, 2023October 22, 2023@timuthy
v1.83Week 43-44October 23, 2023November 5, 2023@oliver-goetz
v1.84Week 45-46November 6, 2023November 19, 2023@rfranzke
v1.85Week 47-48November 20, 2023December 3, 2023@plkokanov
v1.86Week 49-50December 4, 2023December 17, 2023@ialidzhikov
v1.87Week 01-04January 1, 2024January 28, 2024@acumino
v1.88Week 05-06January 29, 2024February 11, 2024@timuthy
v1.89Week 07-08February 12, 2024February 25, 2024@ScheererJ
v1.90Week 09-10February 26, 2024March 10, 2024@ary1992
v1.91Week 11-12March 11, 2024March 24, 2024@shafeeqes
v1.92Week 13-14March 25, 2024April 7, 2024@oliver-goetz
v1.93Week 15-16April 8, 2024April 21, 2024@rfranzke
v1.94Week 17-18April 22, 2024May 5, 2024@plkokanov
v1.95Week 19-20May 6, 2024May 19, 2024@ialidzhikov
v1.96Week 21-22May 20, 2024June 2, 2024@acumino
v1.97Week 23-24June 3, 2024June 16, 2024@timuthy
v1.98Week 25-26June 17, 2024June 30, 2024@ScheererJ
v1.99Week 27-28July 1, 2024July 14, 2024@ary1992
v1.100Week 29-30July 15, 2024July 28, 2024@shafeeqes

Release Validation

The release phase for a new minor version lasts two weeks. Typically, the first week is used for the validation of the release. This phase includes the following steps:

  1. master (or latest release-* branch) is deployed to a development landscape that already hosts some existing seed and shoot clusters.
  2. An extended test suite is triggered by the “release responsible” which:
    1. executes the Gardener integration tests for different Kubernetes versions, infrastructures, and Shoot settings.
    2. executes the Kubernetes conformance tests.
    3. executes further tests like Kubernetes/OS patch/minor version upgrades.
  3. Additionally, every four hours (or on demand) more tests (e.g., including the Kubernetes e2e test suite) are executed for different infrastructures.
  4. The “release responsible” is verifying new features or other notable changes (derived of the draft release notes) in this development system.

Usually, the new release is triggered in the beginning of the second week if all tests are green, all checks were successful, and if all of the planned verifications were performed by the release responsible.

Contributing New Features or Fixes

Please refer to the Gardener contributor guide. Besides a lot of general information, it also provides a checklist for newly created pull requests that may help you to prepare your changes for an efficient review process. If you are contributing a fix or major improvement, please take care to open cherry-pick PRs to all affected and still supported versions once the change is approved and merged in the master branch.

⚠️ Please ensure that your modifications pass the verification checks (linting, formatting, static code checks, tests, etc.) by executing

make verify

before filing your pull request.

The guide applies for both changes to the master and to any release-* branch. All changes must be submitted via a pull request and be reviewed and approved by at least one code owner.

TODO Statements

Sometimes, TODO statements are being introduced when one cannot follow up immediately with certain tasks or when temporary migration code is required. In order to properly follow-up with such TODOs and to prevent them from piling up without getting attention, the following rules should be followed:

  • Each TODO statement should have an associated person and state when it can be removed. Example:
    // TODO(<github-username>): Remove this code after v1.75 has been released.
    
  • When the task depends on a certain implementation, a GitHub issue should be opened and referenced in the statement. Example:
    // TODO(<github-username>): Remove this code after https://github.com/gardener/gardener/issues/<issue-number> has been implemented.
    
    The associated person should actively drive the implementation of the referenced issue (unless it cannot be done because of third-party dependencies or conditions) so that the TODO statement does not get stale.
  • TODO statements without actionable tasks or those that are unlikely to ever be implemented (maybe because of very low priorities) should not be specified in the first place. If a TODO is specified, the associated person should make sure to actively follow-up.

Deprecations and Backwards-Compatibility

In case you have to remove functionality relevant to end-users (e.g., a field or default value in the Shoot API), please connect it with a Kubernetes minor version upgrade. This way, end-users are forced to actively adapt their manifests when they perform their Kubernetes upgrades. For example, the .spec.kubernetes.enableStaticTokenKubeconfig field in the Shoot API is no longer allowed to be set for Kubernetes versions >= 1.27.

In case you have to remove or change functionality which cannot be directly connected with a Kubernetes version upgrade, please consider introducing a feature gate. This way, landscape operators can announce the planned changes to their users and communicate a timeline when they plan to activate the feature gate. End-users can then prepare for it accordingly. For example, the fact that changes to kubelet.kubeReserved in the Shoot API will lead to a rolling update of the worker nodes (previously, these changes were updated in-place) is controlled via the NewWorkerPoolHash feature gate.

In case you have to remove functionality relevant to Gardener extensions, please deprecate it first, and add a TODO statement to remove it only after at least 9 releases. Do not forget to write a proper release note as part of your pull request. This gives extension developers enough time (~18 weeks) to adapt to the changes (and to release a new version of their extension) before Gardener finally removes the functionality. Examples are removing a field in the extensions.gardener.cloud/v1alpha1 API group, or removing a controller in the extensions library.

In case you have to run migration code (which is mostly internal), please add a TODO statement to remove it only after 3 releases. This way, we can ensure that the Gardener version skew policy is not violated. For example, the migration code for moving the Prometheus instances under management of prometheus-operator was running for three releases.

lightbulb-on-outline

Tip

Please revisit the version skew policy.

Cherry Picks

This section explains how to initiate cherry picks on release branches within the gardener/gardener repository.

Prerequisites

Before you initiate a cherry pick, make sure that the following prerequisites are accomplished.

  • A pull request merged against the master branch.
  • The release branch exists (check in the branches section).
  • Have the gardener/gardener repository cloned as follows:
    • the origin remote should point to your fork (alternatively this can be overwritten by passing FORK_REMOTE=<fork-remote>).
    • the upstream remote should point to the Gardener GitHub org (alternatively this can be overwritten by passing UPSTREAM_REMOTE=<upstream-remote>).
  • Have hub installed, which is most easily installed via go get github.com/github/hub assuming you have a standard golang development environment.
  • A GitHub token which has permissions to create a PR in an upstream branch.

Initiate a Cherry Pick

  • Run the [cherry pick script][cherry-pick-script].

    This example applies a master branch PR #3632 to the remote branch upstream/release-v3.14:

    GITHUB_USER=<your-user> hack/cherry-pick-pull.sh upstream/release-v3.14 3632
    
    • Be aware the cherry pick script assumes you have a git remote called upstream that points at the Gardener GitHub org.

    • You will need to run the cherry pick script separately for each patch release you want to cherry pick to. Cherry picks should be applied to all active release branches where the fix is applicable.

    • When asked for your GitHub password, provide the created GitHub token rather than your actual GitHub password. Refer https://github.com/github/hub/issues/2655#issuecomment-735836048

  • cherry-pick-script