sigs.k8s.io/cluster-api@v1.7.1/docs/release/release-cycle.md (about)

     1  # Release Cycle
     2  
     3  The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `v1.3.0`) is released.
     4  
     5  Each release cycle will last approximately 4 months (~ 17 weeks) and it can be split up into the following phases:
     6  
     7  * Week 1-12: Active development
     8      * All changes impacting providers' adoption of Cluster API should be implemented and merged in this period. Exceptions
     9        require special approval as described in the section below.
    10      * Alpha releases will be released based on the main branch only if necessary (to be determined by the release lead)
    11      * Please note that we also publish daily releases based on the main branch.
    12  * Week 13-14: Beta
    13      * Weekly beta releases will be released based on the main branch
    14          * The beta releases are meant as a preview of the upcoming release
    15          * Providers can start adopting the new release based on the beta releases
    16      * All changes that impact providers' adoption of the new release should be announced in the provider updates section
    17        of the office hours meeting notes and approved in the PR or issue by both approvers and key affected providers.
    18          * Non-breaking dependency bumps which don't require provider changes don't have to be explicitly approved
    19            in addition to the regular PR review.
    20  * Week 15-16: RC
    21      * The release branch is created
    22      * Weekly RC releases will be released based on the release branch
    23          * RC releases are as close as possible to the final release but they are still undergoing further testing
    24      * Development of the next release can technically start on the main branch, but some changes might be delayed
    25        to ensure easier cherry-picking of other changes to the release branch.
    26      * There is a feature freeze on the release branch
    27          * Only cherry-picks for documentation, bug fixes, test fixes and test additions are allowed
    28  * Week 17: GA
    29      * `x.y.0` GA release is created based on the release branch
    30  * After that:
    31      * **Note** The following is the responsibility of the release team of the following release cycle.
    32      * `x.y.1+` monthly patch release: Monthly patch releases will be released based on the release branch
    33      * `x.y.1+` extra patch release: In order to quickly provide official support for  a new Kubernetes minor release to Cluster API users,
    34        an additional patch release will be released approximately one week after a new Kubernetes minor release is available.
    35        * The additional patch release will be created only for the latest supported Cluster API minor release.
    36        * The additional patch release might be canceled if: 
    37          * The release date for the additional patch release overlaps the release date of a monthly patch release (+/- 5 business days).
    38          * Cluster API maintainers determine that required changes in Cluster API to support the new release are too
    39            invasive and cannot be back ported.
    40    * Cherry-picks to the release branch are allowed according to the [backport policy](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#backporting-a-patch)
    41    * Providers create releases using the new CAPI minor release when they are ready
    42    * Development of the next release can now officially start on the main branch
    43  
    44  Some additional notes:
    45  
    46  * Support for new Kubernetes minor versions (for management and workload clusters) is first implemented
    47    on the main branch, then cherry-picked into the release branch for the latest minor version only, and then
    48    released according to the `x.y.1+` extra patch release schedule defined above.
    49      * **Note**: We usually don't have to bump Go dependencies to support new Kubernetes minor versions as it's not necessary
    50        to run on a management cluster with the new version or create a workload cluster with the new version.
    51        If it becomes necessary to bump dependencies to a new CR/Kubernetes minor version, the change cannot be cherry-picked
    52        as bumping dependencies to a new minor version is a breaking change.
    53  * New Kubernetes and Controller-Runtime (CR) minor releases are only picked up on the main branch.
    54  
    55  The following diagram visualizes the release cycles with the v1.2, v1.3 and v1.4 releases:
    56  
    57  <!-- The release cycle png can be opened and edited in draw.io -->
    58  ![Release Cycle Overview](release-cycle-overview.png)