docs/devel/stable-process.rst

   1 .. _stable-process:
   2
   3 QEMU and the stable process
   4 ===========================
   5
   6 QEMU stable releases
   7 --------------------
   8
   9 QEMU stable releases are based upon the last released QEMU version
  10 and marked by an additional version number, e.g. 2.10.1. Occasionally,
  11 a four-number version is released, if a single urgent fix needs to go
  12 on top.
  13
  14 Usually, stable releases are only provided for the last major QEMU
  15 release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y
  16 stable releases are produced only until QEMU 2.12.0 is released, at
  17 which point the stable process moves to producing 2.12.x/2.12.x.y releases.
  18
  19 What should go into a stable release?
  20 -------------------------------------
  21
  22 Generally, the following patches are considered stable material:
  23
  24 * Patches that fix severe issues, like fixes for CVEs
  25
  26 * Patches that fix regressions
  27
  28 If you think the patch would be important for users of the current release
  29 (or for a distribution picking fixes), it is usually a good candidate
  30 for stable.
  31
  32
  33 How to get a patch into QEMU stable
  34 -----------------------------------
  35
  36 There are various ways to get a patch into stable:
  37
  38 * Preferred: Make sure that the stable maintainers are on copy when you send
  39   the patch by adding
  40
  41   .. code::
  42
  43      Cc: qemu-stable@nongnu.org
  44
  45   to the patch description. By default, this will send a copy of the patch
  46   to ``qemu-stable@nongnu.org`` if you use git send-email, which is where
  47   patches that are stable candidates are tracked by the maintainers.
  48
  49 * You can also reply to a patch and put ``qemu-stable@nongnu.org`` on copy
  50   directly in your mail client if you think a previously submitted patch
  51   should be considered for a stable release.
  52
  53 * If a maintainer judges the patch appropriate for stable later on (or you
  54   notify them), they will add the same line to the patch, meaning that
  55   the stable maintainers will be on copy on the maintainer's pull request.
  56
  57 * If you judge an already merged patch suitable for stable, send a mail
  58   (preferably as a reply to the most recent patch submission) to
  59   ``qemu-stable@nongnu.org`` along with ``qemu-devel@nongnu.org`` and
  60   appropriate other people (like the patch author or the relevant maintainer)
  61   on copy.
  62
  63 Stable release process
  64 ----------------------
  65
  66 When the stable maintainers prepare a new stable release, they will prepare
  67 a git branch with a release candidate and send the patches out to
  68 ``qemu-devel@nongnu.org`` for review. If any of your patches are included,
  69 please verify that they look fine, especially if the maintainer had to tweak
  70 the patch as part of back-porting things across branches. You may also
  71 nominate other patches that you think are suitable for inclusion. After
  72 review is complete (may involve more release candidates), a new stable release
  73 is made available.