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