1.. stable_lts_releases: 2 3DPDK Stable Releases and Long Term Support 4========================================== 5 6This section sets out the guidelines for the DPDK Stable Releases and the DPDK 7Long Term Support releases (LTS). 8 9 10Introduction 11------------ 12 13The purpose of the DPDK Stable Releases is to maintain releases of DPDK with 14backported fixes over an extended period of time. This provides downstream 15consumers of DPDK with a stable target on which to base applications or 16packages. 17 18The Long Term Support release (LTS) is a designation applied to a Stable 19Release to indicate longer term support. 20 21 22Stable Releases 23--------------- 24 25Any major release of DPDK can be designated as a Stable Release if a 26maintainer volunteers to maintain it. 27 28A Stable Release is used to backport fixes from an ``N`` release back to an 29``N-1`` release, for example, from 16.11 to 16.07. 30 31The duration of a stable is one complete release cycle (3 months). It can be 32longer, up to 1 year, if a maintainer continues to support the stable branch, 33or if users supply backported fixes, however the explicit commitment should be 34for one release cycle. 35 36The release cadence is determined by the maintainer based on the number of 37bugfixes and the criticality of the bugs. Releases should be coordinated with 38the validation engineers to ensure that a tagged release has been tested. 39 40 41LTS Release 42----------- 43 44A stable release can be designated as an LTS release based on community 45agreement and a commitment from a maintainer. The current policy is that each 46year's November release will be maintained as an LTS for 2 years. 47 48The current DPDK LTS releases are 16.11 and 17.11. 49 50It is anticipated that there will be at least 4 releases per year of the LTS 51or approximately 1 every 3 months. However, the cadence can be shorter or 52longer depending on the number and criticality of the backported 53fixes. Releases should be coordinated with the validation engineers to ensure 54that a tagged release has been tested. 55 56 57What changes should be backported 58--------------------------------- 59 60Backporting should be limited to bug fixes. 61 62Features should not be backported to stable releases. It may be acceptable, in 63limited cases, to back port features for the LTS release where: 64 65* There is a justifiable use case (for example a new PMD). 66* The change is non-invasive. 67* The work of preparing the backport is done by the proposer. 68* There is support within the community. 69 70 71The Stable Mailing List 72----------------------- 73 74The Stable and LTS release are coordinated on the stable@dpdk.org mailing 75list. 76 77All fix patches to the master branch that are candidates for backporting 78should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_ 79mailing list. 80 81 82Releasing 83--------- 84 85A Stable Release will be released by: 86 87* Tagging the release with YY.MM.n (year, month, number). 88* Uploading a tarball of the release to dpdk.org. 89* Sending an announcement to the `announce@dpdk.org <http://dpdk.org/ml/listinfo/announce>`_ 90 list. 91 92Stable releases are available on the `dpdk.org download page <http://dpdk.org/download>`_. 93 94 95ABI 96--- 97 98The Stable Release should not be seen as a way of breaking or circumventing 99the DPDK ABI policy. 100