Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 1 | .. _releases: |
| 2 | |
| 3 | Releases |
| 4 | ######## |
| 5 | |
| 6 | .. _releases_cadance: |
| 7 | |
| 8 | Cadence |
| 9 | ******* |
| 10 | New versions of OP-TEE are released four times a year, i.e., quarterly releases. |
| 11 | The releases have historically lined up with Linaro Connect events. I.e., a |
| 12 | release has been made right after Linaro Connect and one release somewhere |
| 13 | between two Linaro Connects. I.e., typically there has been releases in January, |
| 14 | April, July and October. |
| 15 | |
| 16 | .. _releases_changelog: |
| 17 | |
| 18 | Changelog |
| 19 | ********* |
| 20 | The changelog is stored in the :ref:`optee_os` git (CHANGELOG.md_). There you |
| 21 | can see what has been done between the different releases in terms of commits as |
| 22 | well as pull requests. |
| 23 | |
| 24 | .. _releases_versioning_schema: |
| 25 | |
| 26 | Versioning schema |
| 27 | ***************** |
| 28 | OP-TEE follows `Semantic Versioning 2.0.0`_. What that means in practice is well |
| 29 | described at the link just shown. |
| 30 | |
| 31 | .. _releases_release_procedure: |
| 32 | |
| 33 | Release procedure |
| 34 | ***************** |
| 35 | There are certain steps that needs to be done when making a release. This |
| 36 | checklist here serves as guidance to the one in charge of making a new release. |
| 37 | Roughly start with this 2-3 weeks before the targeted release date. |
| 38 | |
| 39 | tl;dr |
| 40 | ===== |
| 41 | .. list-table:: Short version of the OP-TEE release procedure |
| 42 | :widths: 60 300 10 |
| 43 | :header-rows: 1 |
| 44 | |
| 45 | * - When |
| 46 | (Tminus) |
| 47 | - Action |
| 48 | - Example |
| 49 | |
| 50 | * - 3w |
| 51 | - Create release pull request |
| 52 | - `PR#3099`_ |
| 53 | |
| 54 | * - 3w |
| 55 | - Inform maintainers about upcoming release |
| 56 | - |
| 57 | |
| 58 | * - 1w |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 59 | - Increment the revision number in `mk/config.mk`_ |
| 60 | - ``CFG_OPTEE_REVISION_MAJOR ?= 3`` ``CFG_OPTEE_REVISION_MINOR ?= x`` |
| 61 | |
| 62 | * - 1w |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 63 | - Create release candidate tag in optee_* + build.git |
| 64 | - git tag -a 3.x.y-rc1 -m "3.x.y-rc1" |
| 65 | |
| 66 | * - 1w |
| 67 | - Let maintainers know about the release candidate tag |
| 68 | - |
| 69 | |
| 70 | * - 1w |
| 71 | - Test platform builds / devices |
| 72 | - |
| 73 | |
| 74 | * - Release day |
| 75 | - Update CHANGELOG.md_ |
| 76 | - `changelog example`_ |
| 77 | |
| 78 | * - Release day |
| 79 | - Collect/merge ``Tested-By`` tags |
| 80 | - `commit example`_ |
| 81 | |
| 82 | * - Release day |
| 83 | - Create release tag in optee_* + build.git |
| 84 | - git tag -a 3.x.y -m "3.x.y" |
| 85 | |
| 86 | * - Release day |
| 87 | - Create release branch in :ref:`manifest` |
| 88 | - git checkout -b 3.x.y origin/master |
| 89 | |
| 90 | * - Release day |
| 91 | - Update manifest XML-files |
| 92 | - `3.6.0 stable`_ |
| 93 | |
| 94 | * - Release day |
| 95 | - Inform maintainers and stakeholder that release has been completed. |
| 96 | - |
| 97 | |
| 98 | |
| 99 | Long version |
| 100 | ============ |
| 101 | |
| 102 | 1. Create a "release pull request" at GitHub ought to collect ``Tested-By`` |
| 103 | tags from various maintainers. As an example, see `PR#3099`_. |
| 104 | |
| 105 | 2. Send email to all maintainers to let them know about the upcoming |
| 106 | release. The addresses to the maintainers can be found in the |
| 107 | MAINTAINERS_ file. |
| 108 | |
| 109 | .. hint:: |
Jerome Forissier | 50685cf | 2020-02-20 08:39:35 +0100 | [diff] [blame] | 110 | With this command you will get all email addresses |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 111 | |
| 112 | .. code-block:: bash |
| 113 | |
Jerome Forissier | 50685cf | 2020-02-20 08:39:35 +0100 | [diff] [blame] | 114 | $ scripts/get_maintainer.py --release-to |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 115 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 116 | 3. Increment the revision number in `mk/config.mk`: |
| 117 | ``CFG_OPTEE_REVISION_MAJOR`` and ``CFG_OPTEE_REVISION_MINOR``. These |
| 118 | values are made available to TAs and to the Normal World driver at boot |
| 119 | time. |
| 120 | |
| 121 | 4. Create a release candidate (RC) tag (annotated tag, i.e., ``git tag -a |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 122 | 3.x.y-rc1 -m "3.x.y-rc1"``) in the following gits |
| 123 | ``optee_*`` and ``build.git``. One way to do it is like this |
| 124 | |
| 125 | .. code-block:: bash |
| 126 | |
| 127 | $ export VER=3.x.y-rc1 |
| 128 | $ for d in optee* build; do ( cd $d; git tag -a $VER -m $VER ); done |
| 129 | $ for d in optee* build; do ( cd $d; git push origin $VER ); done |
| 130 | |
| 131 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 132 | 5. Send a follow up email to all maintainers to let them know that there is |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 133 | a release tag ready to be tested on their devices for the platforms that |
| 134 | they are maintaining. |
| 135 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 136 | 6. In case major regressions are found, then fix those and create a another |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 137 | release candidate tag (i.e., repeat step 3 and 4 until there are no |
| 138 | remaining issues left). |
| 139 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 140 | 7. On release day: Update CHANGELOG.md_ see this `changelog example`_ to see |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 141 | how that should look like. |
| 142 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 143 | 8. Collect all tags (``Tested-By`` etc) from maintainers and use those in |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 144 | the commit message, for an example see this `commit example`_. |
| 145 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 146 | 9. Create a release tag (annotated tag, i.e., ``git tag -a 3.x.y -m |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 147 | "3.x.y"``) in the following gits ``optee_*`` and ``build.git``. |
| 148 | |
| 149 | .. hint:: |
| 150 | |
Jerome Forissier | fe88261 | 2020-01-28 10:48:46 +0100 | [diff] [blame] | 151 | You can use the same steps as in step 4, when creating the tags. |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 152 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 153 | 10. Create a new branch in :ref:`manifest` from ``master`` where the name |
| 154 | corresponds to the release you are preparing. I.e., ``git checkout -b |
| 155 | 3.x.y origin/master``. |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 156 | |
| 157 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 158 | 11. Update all :ref:`manifest` XML-files in the :ref:`manifest` git, so they |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 159 | refer to the tag in the release we are working with (see `3.6.0 stable`_ |
| 160 | commit as an example). This can be done with the make_stable.sh_ script. |
| 161 | Now it is also time to push the new branch and tag it. Example: |
| 162 | |
| 163 | .. code-block:: bash |
| 164 | |
| 165 | $ export VER=3.x.y |
| 166 | $ cd manifest |
| 167 | $ ./make_stable.sh -o -r $VER |
| 168 | $ git diff # make sure everything looks good |
| 169 | $ git commit -a -m "OP-TEE $VER stable" |
| 170 | $ git remote add upstream git@github.com:OP-TEE/manifest |
| 171 | $ git push upstream |
Jerome Forissier | c8f6061 | 2020-01-28 10:51:27 +0100 | [diff] [blame] | 172 | $ git tag -a $VER -m $VER |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 173 | $ git push upstream tag $VER |
| 174 | |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 175 | 12. Send a last email to maintainers and other stakeholders telling that the |
Joakim Bech | 6e53df7 | 2019-09-18 16:57:23 +0200 | [diff] [blame] | 176 | release has been completed. |
| 177 | |
| 178 | |
| 179 | .. _3.6.0 stable: https://github.com/OP-TEE/manifest/commit/f181e959c21baddce82552104daf81a25f8fd898 |
| 180 | .. _CHANGELOG.md: https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md |
| 181 | .. _changelog example: https://github.com/OP-TEE/optee_os/commit/f398d4923da875370149ffee45c963d7adb41495#diff-4ac32a78649ca5bdd8e0ba38b7006a1e |
| 182 | .. _commit example: https://github.com/OP-TEE/optee_os/commit/f398d4923da875370149ffee45c963d7adb41495 |
| 183 | .. _MAINTAINERS: https://github.com/OP-TEE/optee_os/blob/master/MAINTAINERS |
| 184 | .. _make_stable.sh: https://github.com/OP-TEE/manifest/blob/master/make_stable.sh |
| 185 | .. _PR#3099: https://github.com/OP-TEE/optee_os/pull/3099 |
| 186 | .. _Semantic Versioning 2.0.0: https://semver.org |
Jerome Forissier | a42d1c1 | 2019-10-15 09:45:34 +0200 | [diff] [blame] | 187 | .. _mk/config.mk: https://github.com/OP-TEE/optee_os/blob/master/mk/config.mk |