xref: /dpdk/doc/guides/contributing/stable.rst (revision 3cc6ecfdfe85d2577fef30e1791bb7534e3d60b3)
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 Long Term Support release (LTS) is a designation applied to a Stable
22Release to indicate longer term support.
23
24
25Stable Releases
26---------------
27
28Any release of DPDK can be designated as a Stable Release if a
29maintainer volunteers to maintain it and there is a commitment from major
30contributors to validate it before releases.
31If a version is to be a "Stable Release", it should be designated as such
32within one month of that version being initially released.
33
34A Stable Release is used to backport fixes from an ``N`` release back to an
35``N-1`` release, for example, from 16.11 to 16.07.
36
37The duration of a stable is one complete release cycle (3 months). It can be
38longer, up to 1 year, if a maintainer continues to support the stable branch,
39or if users supply backported fixes, however the explicit commitment should be
40for one release cycle.
41
42The release cadence is determined by the maintainer based on the number of
43bugfixes and the criticality of the bugs. Releases should be coordinated with
44the validation engineers to ensure that a tagged release has been tested.
45
46
47LTS Release
48-----------
49
50A stable release can be designated as an LTS release based on community
51agreement and a commitment from a maintainer. The current policy is that each
52year's November (X.11) release will be maintained as an LTS for 2 years.
53
54After the X.11 release, an LTS branch will be created for it at
55https://git.dpdk.org/dpdk-stable where bugfixes will be backported to.
56
57A LTS release may align with the declaration of a new major ABI version,
58please read the :doc:`abi_policy` for more information.
59
60It is anticipated that there will be at least 4 releases per year of the LTS
61or approximately 1 every 3 months. However, the cadence can be shorter or
62longer depending on the number and criticality of the backported
63fixes. Releases should be coordinated with the validation engineers to ensure
64that a tagged release has been tested.
65
66For a list of the currently maintained stable/LTS branches please see
67the latest `stable roadmap <https://core.dpdk.org/roadmap/#stable>`_.
68
69At the end of the 2 years, a final X.11.N release will be made and at that
70point the LTS branch will no longer be maintained with no further releases.
71
72
73What changes should be backported
74---------------------------------
75
76Backporting should be limited to bug fixes. All patches accepted on the main
77branch with a Fixes: tag should be backported to the relevant stable/LTS
78branches, unless the submitter indicates otherwise. If there are exceptions,
79they will be discussed on the mailing lists.
80
81Fixes suitable for backport should have a ``Cc: stable@dpdk.org`` tag in the
82commit message body as follows::
83
84     doc: fix some parameter description
85
86     Update the docs, fixing description of some parameter.
87
88     Fixes: abcdefgh1234 ("doc: add some parameter")
89     Cc: stable@dpdk.org
90
91     Signed-off-by: Alex Smith <alex.smith@example.com>
92
93
94Fixes not suitable for backport should not include the ``Cc: stable@dpdk.org`` tag.
95
96Features should not be backported to stable releases. It may be acceptable, in
97limited cases, to back port features for the LTS release where:
98
99* There is a justifiable use case (for example a new PMD).
100* The change is non-invasive.
101* The work of preparing the backport is done by the proposer.
102* There is support within the community.
103
104
105The Stable Mailing List
106-----------------------
107
108The Stable and LTS release are coordinated on the stable@dpdk.org mailing
109list.
110
111All fix patches to the main branch that are candidates for backporting
112should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
113mailing list.
114
115
116Releasing
117---------
118
119A Stable Release will be released by:
120
121* Tagging the release with YY.MM.n (year, month, number).
122* Uploading a tarball of the release to dpdk.org.
123* Sending an announcement to the `announce@dpdk.org <https://mails.dpdk.org/listinfo/announce>`_
124  list.
125
126Stable releases are available on the `dpdk.org download page <https://core.dpdk.org/download/>`_.
127