1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright 2018 The DPDK contributors 3 4.. _stable_lts_releases: 5 6DPDK Stable Releases and Long Term Support 7========================================== 8 9This section sets out the guidelines for the DPDK Stable Releases and the DPDK 10Long Term Support releases (LTS). 11 12 13Introduction 14------------ 15 16The purpose of the DPDK Stable Releases is to maintain releases of DPDK with 17backported fixes over an extended period of time. This provides downstream 18consumers of DPDK with a stable target on which to base applications or 19packages. 20 21The primary characteristics of stable releases is that they attempt to 22fix issues and not introduce any new regressions while keeping backwards 23compatibility with the initial release of the stable version. 24 25The Long Term Support release (LTS) is a designation applied to a Stable 26Release to indicate longer term support. 27 28 29Stable Releases 30--------------- 31 32Any release of DPDK can be designated as a Stable Release if a 33maintainer volunteers to maintain it and there is a commitment from major 34contributors to validate it before releases. 35If a version is to be a "Stable Release", it should be designated as such 36within one month of that version being initially released. 37 38A Stable Release is used to backport fixes from an ``N`` release back to an 39``N-1`` release, for example, from 16.11 to 16.07. 40 41The duration of a stable is one complete release cycle (4 months). It can be 42longer, up to 1 year, if a maintainer continues to support the stable branch, 43or if users supply backported fixes, however the explicit commitment should be 44for one release cycle. 45 46The release cadence is determined by the maintainer based on the number of 47bugfixes and the criticality of the bugs. Releases should be coordinated with 48the validation engineers to ensure that a tagged release has been tested. 49 50 51LTS Release 52----------- 53 54A stable release can be designated as an LTS release based on community 55agreement and a commitment from a maintainer. The current policy is that each 56year's November (X.11) release will be maintained as an LTS for 3 years, 57however that is dependent on continued community support for validation. 58 59After the X.11 release, an LTS branch will be created for it at 60https://git.dpdk.org/dpdk-stable where bugfixes will be backported to. 61 62A LTS release may align with the declaration of a new major ABI version, 63please read the :doc:`abi_policy` for more information. 64 65It is anticipated that there will be at least 3 releases per year of the LTS 66or approximately 1 every 4 months. This is done to align with the DPDK main 67branch releases so that fixes have already gone through validation as part of 68the DPDK main branch release validation. However, the cadence can be shorter or 69longer depending on the number and criticality of the backported 70fixes. Releases should be coordinated with the validation engineers to ensure 71that a tagged release has been tested. 72 73For a list of the currently maintained stable/LTS branches please see 74the latest `stable roadmap <https://core.dpdk.org/roadmap/#stable>`_. 75 76At the end of the 2 years, a final X.11.N release will be made and at that 77point the LTS branch will no longer be maintained with no further releases. 78 79 80What changes should be backported 81--------------------------------- 82 83Backporting should be limited to bug fixes. All patches accepted on the main 84branch with a Fixes: tag should be backported to the relevant stable/LTS 85branches, unless the submitter indicates otherwise. If there are exceptions, 86they will be discussed on the mailing lists. 87 88Fixes suitable for backport should have a ``Cc: stable@dpdk.org`` tag in the 89commit message body as follows:: 90 91 doc: fix some parameter description 92 93 Update the docs, fixing description of some parameter. 94 95 Fixes: abcdefgh1234 ("doc: add some parameter") 96 Cc: stable@dpdk.org 97 98 Signed-off-by: Alex Smith <alex.smith@example.com> 99 100 101Fixes not suitable for backport should not include the ``Cc: stable@dpdk.org`` tag. 102 103To support the goal of stability and not introducing regressions, 104new code being introduced is limited to bug fixes. 105New features should not be backported to stable releases. 106 107In some limited cases, it may be acceptable to backport a new feature 108to a stable release. Some of the factors which impact the decision by 109stable maintainers are as follows: 110 111* Does the feature break API/ABI? 112* Does the feature break backwards compatibility? 113* Is it for the latest LTS release (to avoid LTS upgrade issues)? 114* Is there a commitment from the proposer or affiliation to validate the feature 115 and check for regressions in related functionality? 116* Is there a track record of the proposer or affiliation validating stable releases? 117* Is it obvious that the feature will not impact existing functionality? 118* How intrusive is the code change? 119* What is the scope of the code change? 120* Does it impact common components or vendor specific? 121* Is there a justifiable use case (a clear user need)? 122* Is there a community consensus about the backport? 123 124Performance improvements are generally not considered to be fixes, 125but may be considered in some cases where: 126 127* It is fixing a performance regression that occurred previously. 128* An existing feature in LTS is not usable as intended without it. 129 130APIs marked as ``experimental`` are not considered part of the ABI version 131and can be changed without prior notice. This is necessary for the API to be 132improved and stabilized and become part of the ABI version in the future. 133 134However, in LTS releases ``experimental`` API should not be changed as there 135will not be a future ABI version on the branch and compatibility with previous 136release of an LTS version is of the highest importance. 137 138The Stable Mailing List 139----------------------- 140 141The Stable and LTS release are coordinated on the stable@dpdk.org mailing 142list. 143 144All fix patches to the main branch that are candidates for backporting 145should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_ 146mailing list. 147 148 149Releasing 150--------- 151 152A Stable Release will be released by: 153 154* Tagging the release with YY.MM.n (year, month, number). 155* Uploading a tarball of the release to dpdk.org. 156* Sending an announcement to the `announce@dpdk.org <https://mails.dpdk.org/listinfo/announce>`_ 157 list. 158 159Stable releases are available on the `dpdk.org download page <https://core.dpdk.org/download/>`_. 160