xref: /openbmc/qemu/docs/devel/stable-process.rst (revision 2df1eb27)
1.. _stable-process:
2
3QEMU and the stable process
4===========================
5
6QEMU stable releases
7--------------------
8
9QEMU stable releases are based upon the last released QEMU version
10and marked by an additional version number, e.g. 2.10.1. Occasionally,
11a four-number version is released, if a single urgent fix needs to go
12on top.
13
14Usually, stable releases are only provided for the last major QEMU
15release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y
16stable releases are produced only until QEMU 2.12.0 is released, at
17which point the stable process moves to producing 2.12.x/2.12.x.y releases.
18
19What should go into a stable release?
20-------------------------------------
21
22Generally, 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
28If 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
30for stable.
31
32
33How to get a patch into QEMU stable
34-----------------------------------
35
36There 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
63Stable release process
64----------------------
65
66When the stable maintainers prepare a new stable release, they will prepare
67a 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,
69please verify that they look fine, especially if the maintainer had to tweak
70the patch as part of back-porting things across branches. You may also
71nominate other patches that you think are suitable for inclusion. After
72review is complete (may involve more release candidates), a new stable release
73is made available.
74