]>
Commit | Line | Data |
---|---|---|
11fdf7f2 TL |
1 | .. SPDX-License-Identifier: BSD-3-Clause |
2 | Copyright 2018 The DPDK contributors | |
3 | ||
f67539c2 | 4 | .. _stable_lts_releases: |
11fdf7f2 TL |
5 | |
6 | DPDK Stable Releases and Long Term Support | |
7 | ========================================== | |
8 | ||
9 | This section sets out the guidelines for the DPDK Stable Releases and the DPDK | |
10 | Long Term Support releases (LTS). | |
11 | ||
12 | ||
13 | Introduction | |
14 | ------------ | |
15 | ||
16 | The purpose of the DPDK Stable Releases is to maintain releases of DPDK with | |
17 | backported fixes over an extended period of time. This provides downstream | |
18 | consumers of DPDK with a stable target on which to base applications or | |
19 | packages. | |
20 | ||
21 | The Long Term Support release (LTS) is a designation applied to a Stable | |
22 | Release to indicate longer term support. | |
23 | ||
24 | ||
25 | Stable Releases | |
26 | --------------- | |
27 | ||
f67539c2 | 28 | Any release of DPDK can be designated as a Stable Release if a |
9f95a23c TL |
29 | maintainer volunteers to maintain it and there is a commitment from major |
30 | contributors to validate it before releases. If a release is to be designated | |
31 | as a Stable Release, it should be done by 1 month after the master release. | |
11fdf7f2 TL |
32 | |
33 | A 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 | ||
36 | The duration of a stable is one complete release cycle (3 months). It can be | |
37 | longer, up to 1 year, if a maintainer continues to support the stable branch, | |
38 | or if users supply backported fixes, however the explicit commitment should be | |
39 | for one release cycle. | |
40 | ||
41 | The release cadence is determined by the maintainer based on the number of | |
42 | bugfixes and the criticality of the bugs. Releases should be coordinated with | |
43 | the validation engineers to ensure that a tagged release has been tested. | |
44 | ||
45 | ||
46 | LTS Release | |
47 | ----------- | |
48 | ||
49 | A stable release can be designated as an LTS release based on community | |
50 | agreement and a commitment from a maintainer. The current policy is that each | |
9f95a23c | 51 | year's November (X.11) release will be maintained as an LTS for 2 years. |
11fdf7f2 | 52 | |
9f95a23c | 53 | After the X.11 release, an LTS branch will be created for it at |
f67539c2 TL |
54 | https://git.dpdk.org/dpdk-stable where bugfixes will be backported to. |
55 | ||
56 | A LTS release may align with the declaration of a new major ABI version, | |
57 | please read the :doc:`abi_policy` for more information. | |
11fdf7f2 TL |
58 | |
59 | It is anticipated that there will be at least 4 releases per year of the LTS | |
60 | or approximately 1 every 3 months. However, the cadence can be shorter or | |
61 | longer depending on the number and criticality of the backported | |
62 | fixes. Releases should be coordinated with the validation engineers to ensure | |
63 | that a tagged release has been tested. | |
64 | ||
f67539c2 TL |
65 | For a list of the currently maintained stable/LTS branches please see |
66 | the latest `stable roadmap <https://core.dpdk.org/roadmap/#stable>`_. | |
9f95a23c TL |
67 | |
68 | At the end of the 2 years, a final X.11.N release will be made and at that | |
69 | point the LTS branch will no longer be maintained with no further releases. | |
70 | ||
11fdf7f2 TL |
71 | |
72 | What changes should be backported | |
73 | --------------------------------- | |
74 | ||
75 | Backporting should be limited to bug fixes. All patches accepted on the master | |
76 | branch with a Fixes: tag should be backported to the relevant stable/LTS | |
77 | branches, unless the submitter indicates otherwise. If there are exceptions, | |
78 | they will be discussed on the mailing lists. | |
79 | ||
80 | Fixes suitable for backport should have a ``Cc: stable@dpdk.org`` tag in the | |
81 | commit 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 | ||
93 | Fixes not suitable for backport should not include the ``Cc: stable@dpdk.org`` tag. | |
94 | ||
95 | Features should not be backported to stable releases. It may be acceptable, in | |
96 | limited 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 | ||
104 | The Stable Mailing List | |
105 | ----------------------- | |
106 | ||
107 | The Stable and LTS release are coordinated on the stable@dpdk.org mailing | |
108 | list. | |
109 | ||
110 | All fix patches to the master branch that are candidates for backporting | |
f67539c2 | 111 | should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_ |
11fdf7f2 TL |
112 | mailing list. |
113 | ||
114 | ||
115 | Releasing | |
116 | --------- | |
117 | ||
118 | A 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 | 125 | Stable releases are available on the `dpdk.org download page <https://core.dpdk.org/download/>`_. |