doc/guides/contributing/stable.rst

   1 ..  SPDX-License-Identifier: BSD-3-Clause
   2     Copyright 2018 The DPDK contributors
   3
   4 .. _stable_lts_releases:
   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
  28 Any release of DPDK can be designated as a Stable Release if a
  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.
  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
  51 year's November (X.11) release will be maintained as an LTS for 2 years.
  52
  53 After the X.11 release, an LTS branch will be created for it at
  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.
  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
  65 For a list of the currently maintained stable/LTS branches please see
  66 the latest `stable roadmap <https://core.dpdk.org/roadmap/#stable>`_.
  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
  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
 111 should also be CCed to the `stable@dpdk.org <https://mails.dpdk.org/listinfo/stable>`_
 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.
 122 * Sending an announcement to the `announce@dpdk.org <https://mails.dpdk.org/listinfo/announce>`_
 123   list.
 124
 125 Stable releases are available on the `dpdk.org download page <https://core.dpdk.org/download/>`_.