git.droids-corp.org
/
dpdk.git
/ blobdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
|
commitdiff
|
tree
raw
|
inline
| side by side
maintainers: add Windows exports script
[dpdk.git]
/
doc
/
guides
/
contributing
/
stable.rst
diff --git
a/doc/guides/contributing/stable.rst
b/doc/guides/contributing/stable.rst
index
4214103
..
6a5eee9
100644
(file)
--- a/
doc/guides/contributing/stable.rst
+++ b/
doc/guides/contributing/stable.rst
@@
-26,7
+26,9
@@
Stable Releases
---------------
Any major release of DPDK can be designated as a Stable Release if a
---------------
Any major release of DPDK can be designated as a Stable Release if a
-maintainer volunteers to maintain it.
+maintainer volunteers to maintain it and there is a commitment from major
+contributors to validate it before releases. If a release is to be designated
+as a Stable Release, it should be done by 1 month after the master release.
A Stable Release is used to backport fixes from an ``N`` release back to an
``N-1`` release, for example, from 16.11 to 16.07.
A Stable Release is used to backport fixes from an ``N`` release back to an
``N-1`` release, for example, from 16.11 to 16.07.
@@
-46,9
+48,10
@@
LTS Release
A stable release can be designated as an LTS release based on community
agreement and a commitment from a maintainer. The current policy is that each
A stable release can be designated as an LTS release based on community
agreement and a commitment from a maintainer. The current policy is that each
-year's November release will be maintained as an LTS for 2 years.
+year's November
(X.11)
release will be maintained as an LTS for 2 years.
-The current DPDK LTS releases are 17.11 and 18.11.
+After the X.11 release, an LTS branch will be created for it at
+http://git.dpdk.org/dpdk-stable where bugfixes will be backported to.
It is anticipated that there will be at least 4 releases per year of the LTS
or approximately 1 every 3 months. However, the cadence can be shorter or
It is anticipated that there will be at least 4 releases per year of the LTS
or approximately 1 every 3 months. However, the cadence can be shorter or
@@
-56,6
+59,11
@@
longer depending on the number and criticality of the backported
fixes. Releases should be coordinated with the validation engineers to ensure
that a tagged release has been tested.
fixes. Releases should be coordinated with the validation engineers to ensure
that a tagged release has been tested.
+The current maintained LTS branches are 17.11 and 18.11.
+
+At the end of the 2 years, a final X.11.N release will be made and at that
+point the LTS branch will no longer be maintained with no further releases.
+
What changes should be backported
---------------------------------
What changes should be backported
---------------------------------