This document sets out the guidelines for DPDK Stable Releases and Long Term Support releases (LTS) based on the initial RFC and comments: http://dpdk.org/ml/archives/dev/2016-June/040256.html.
In particular it incorporates suggestions for a Stable Release structure as well as a Long Term Support release. Introduction ------------ The purpose of the DPDK Stable Releases will be to maintain releases of DPDK with backported fixes over an extended period of time. This will provide downstream consumers of DPDK with a stable target on which to base applications or packages. The Long Term Support release (LTS) will be a designation applied to a Stable Release to indicate longer support. Stable Releases --------------- Any major release of DPDK can be designated as a Stable Release if a maintainer volunteers to maintain it. A Stable Release will be used to backport fixes from a N release back to a N-1 release, for example, from 16.11 to 16.07. The duration of a stable release should be one complete release cycle. It can be longer, up to 1 year, if a maintainer continues to support the stable branch, or if users supply backported fixes, however the explicit commitment should be for one release cycle. The release cadence can be determined by the maintainer based on the number of bugfixes and the criticality of the bugs. However, releases should be coordinated with the validation engineers to ensure that a tagged release has been tested. LTS Release ----------- A stable release can be designated as an LTS release based on community agreement and a commitment from a maintainer. An LTS release will have a maintenance duration of 2 years. It is anticipated that there should be at least 4 releases per year of the LTS or approximately 1 every 3 months. However, the cadence can be shorter or 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. Initial Stable Release ---------------------- The initial DPDK Stable Release will be 16.07. It will be viewed as a trial of the Stable Release/LTS policy to determine what are the best working practices for DPDK. The maintainer for the initial release will be Yuanhan Liu <yuanhan.liu at linux.intel.com>. It is hoped that other community members will volunteer as maintainers for other Stable Releases. The initial targeted release for LTS is proposed to be 16.11 based on the results of the work carried out on the 16.07 Stable Release. A list has been set up for Stable Release/LTS specific discussions: <stable at dpdk.org>. This address can also be used for CCing maintainers on bug fix submissions. What changes should be backported --------------------------------- The backporting should be limited to bug fixes. Features should not be backported to stable releases. It may be acceptable, in limited cases, to back port features for the LTS release where: * There is a justifiable use case (for example a new PMD). * The change is non-invasive. * The work of preparing the backport is done by the proposer. * There is support within the community. Testing ------- Stable and LTS releases should be tested before release/tagging. Intel will provide validation engineers to test the 16.07 Stable Release and the initial LTS tree. Other community members should provide testing for other stable releases. The validation will consist of compilation testing on the range of OSes supported by the master release and functional/performance testing on the current major/LTS release of the following OSes: * Ubuntu * RHEL * SuSE * FreeBSD Releasing --------- A Stable Release will be released by: * Tagging the release with YY.MM.nn (year, month, number) or similar. * Uploading a tarball of the release to dpdk.org. * Sending an announcement to the <announce at dpdk.org> list. ABI --- The Stable Release should not be seen as a way of breaking or circumventing the DPDK ABI policy. Review of the Stable Release/LTS guidelines ------------------------------------------- This document serves as a set of guidelines for the planned Stable Releases/LTS activities. However, the actual process can be reviewed and amended over time, based on experiences and feedback.
