[dpdk-dev] DPDK Stable Releases and Long Term Support

[Panu Matilainen]

[ Yes I'm late to this party, apologies for missing the first round of 
discussion ]

On 07/28/2016 03:33 PM, Mcnamara, John wrote:
>
> 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.

A new PMD also would not touch existing code, which makes it a 
low-to-no-risk thing. Ditto for, say, new command line tool or an example.

> * 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.

I find this a strange thing to say about a stable/LTS release ABI. I had 
read the originating thread before seeing this, but it still made me go 
"Huh?" for several seconds. The problem perhaps being, the rest of the 
document addresses stable/LTS releases, but this statement speaks about 
normal development work going on elsewhere.

The earlier version had a mention about ABI/API breakage related to 
things what not to backport but that's entirely gone here. Given how 
important ABI + API stability is for stable/LTS releases, I think it 
deserves a special mention here. Maybe something more to the tune of:

---
ABI or API breakages are not permitted in stable releases, special care 
must be taken to when backporting.

The existence of stable release(s) does not lessen the need to comply to 
DPDK ABI policy in development work.
---

>
>
> 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.
>

With the exception of the ABI/API thing, this looks like a fair starting 
point to me. Time and experience will tell more.

	 - Panu -