github.com/cilium/cilium@v1.16.2/Documentation/contributing/release/organization.rst (about)

     1  .. only:: not (epub or latex or html)
     2    
     3      WARNING: You are looking at unreleased Cilium documentation.
     4      Please use the official rendered version released here:
     5      https://docs.cilium.io
     6  
     7  Organization
     8  ============
     9  
    10  Release Cadence
    11  ---------------
    12  
    13  New feature releases of Cilium are released on a cadence of around six months.
    14  Minor releases are typically designated by incrementing the ``Y`` in the
    15  version format ``X.Y.Z``.
    16  
    17  Three stable branches are maintained at a time: One for the most recent minor
    18  release, and two for the prior two minor releases. For each minor release that
    19  is currently maintained, the stable branch ``vX.Y`` on github contains the code
    20  for the next stable release. New patch releases for an existing stable version
    21  ``X.Y.Z`` are published incrementing the ``Z`` in the version format.
    22  
    23  New patch releases for stable branches are made periodically to provide
    24  security and bug fixes, based upon community demand and bugfix severity.
    25  Potential fixes for an upcoming release are first merged into the ``main``
    26  branch, then backported to the relevant stable branches according to the
    27  :ref:`backport_criteria`.
    28  
    29  The following sections describe in more detail the general guidelines that the
    30  release management team follows for Cilium. The team may diverge from this
    31  process at their discretion.
    32  
    33  Feature Releases
    34  ~~~~~~~~~~~~~~~~
    35  
    36  There are several key dates during the feature development cycle of Cilium
    37  which are important for developers:
    38  
    39  * Pre-release days: The Cilium release management team aims to publish a
    40    snapshot of the latest changes in the ``main`` branch on the first weekday of
    41    each month. This provides developers a target delivery date to incrementally
    42    ship functionality, and allows community members to get early access to
    43    upcoming features to test and provide feedback. Pre-releases may not be
    44    published when a release candidate or final stable release is being
    45    published.
    46  
    47  * Feature freeze: Around six weeks prior to a target feature release, the
    48    ``main`` branch is frozen for new feature contributions. The goal of the
    49    freeze is to focus community attention on stabilizing and hardening the
    50    upcoming release by prioritizing bugfixes, documentation improvements, and
    51    tests. In general, all new functionality that the community intends to
    52    distribute as part of the upcoming release must land into the ``main`` branch
    53    prior to this date. Any bugfixes, docs changes, or testing improvements can
    54    continue to be merged as usual following this date.
    55  
    56  * Release candidates: Following the feature freeze, the release management team
    57    publishes a series of release candidates. These candidates should represent
    58    the functionality and behaviour of the final release. The release management
    59    team encourages community participation in testing and providing feedback on
    60    the release candidates, as this feedback is crucial to identifying any issues
    61    that may not have been discovered during development. Problems identified
    62    during this period may be reported as known issues in the final release or
    63    fixed, subject to severity and community contributions towards solutions.
    64    Release candidates are typically published every two weeks until the final
    65    release is published.
    66  
    67  * Branching and feature thaw: Within two weeks of the feature freeze, the
    68    release management team aims to create a new branch to manage updates for the
    69    new stable feature release series. After this, all Pull Requests for the
    70    upcoming feature release must be labeled with a ``needs-backport/X.Y`` label
    71    with ``X.Y`` matching the target minor release version to trigger the
    72    backporting process and ensure the changes are ported to the release branch.
    73    The ``main`` branch is then unfrozen for feature changes and refactoring.
    74    Until the final release date, it is better to avoid invasive refactoring or
    75    significant new feature additions just to minimize the impact on backporting
    76    for the upcoming release during that period.
    77  
    78  * Stable release: The new feature release ``X.Y.0`` version is published. All
    79    restrictions on submissions are lifted, and the cycle begins again.
    80  
    81  Stable Releases
    82  ~~~~~~~~~~~~~~~
    83  
    84  The Cilium release management team typically aims to publish fresh releases for
    85  all maintained stable branches around the middle of each month. All changes
    86  that are merged into the target branch by the first week of the month should
    87  typically be published in that month's patch release. Changes which do not land
    88  into the target branch by that time may be deferred to the following month's
    89  patch release. For more information about how patches are merged into the
    90  ``main`` branch and subsequently backported to stable branches, see the
    91  :ref:`backport_process`.