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