Kashyap Chamarthy | cd6b167 | 2021-11-19 20:31:17 +0100 | [diff] [blame] | 1 | .. _stable-process: |
| 2 | |
Cornelia Huck | 7aa5422 | 2018-02-09 14:03:33 +0100 | [diff] [blame] | 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: |
Cornelia Huck | 174b72a | 2020-01-13 11:30:23 +0100 | [diff] [blame] | 23 | |
| 24 | * Patches that fix severe issues, like fixes for CVEs |
| 25 | |
| 26 | * Patches that fix regressions |
Cornelia Huck | 7aa5422 | 2018-02-09 14:03:33 +0100 | [diff] [blame] | 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. |