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