blob: bf17109c4c3b7c449ade233547e46bbb907a7761 [file] [log] [blame]
Joakim Bech6e53df72019-09-18 16:57:23 +02001.. _releases:
2
3Releases
4########
5
6.. _releases_cadance:
7
8Cadence
9*******
10New versions of OP-TEE are released four times a year, i.e., quarterly releases.
11The releases have historically lined up with Linaro Connect events. I.e., a
12release has been made right after Linaro Connect and one release somewhere
13between two Linaro Connects. I.e., typically there has been releases in January,
14April, July and October.
15
16.. _releases_changelog:
17
18Changelog
19*********
20The changelog is stored in the :ref:`optee_os` git (CHANGELOG.md_). There you
21can see what has been done between the different releases in terms of commits as
22well as pull requests.
23
24.. _releases_versioning_schema:
25
26Versioning schema
27*****************
28OP-TEE follows `Semantic Versioning 2.0.0`_. What that means in practice is well
29described at the link just shown.
30
31.. _releases_release_procedure:
32
33Release procedure
34*****************
35There are certain steps that needs to be done when making a release. This
36checklist here serves as guidance to the one in charge of making a new release.
37Roughly start with this 2-3 weeks before the targeted release date.
38
39tl;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 Forissiera42d1c12019-10-15 09:45:34 +020059 - Increment the revision number in `mk/config.mk`_
60 - ``CFG_OPTEE_REVISION_MAJOR ?= 3`` ``CFG_OPTEE_REVISION_MINOR ?= x``
61
62 * - 1w
Joakim Bech6e53df72019-09-18 16:57:23 +020063 - 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
99Long 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 Forissier50685cf2020-02-20 08:39:35 +0100110 With this command you will get all email addresses
Joakim Bech6e53df72019-09-18 16:57:23 +0200111
112 .. code-block:: bash
113
Jerome Forissier50685cf2020-02-20 08:39:35 +0100114 $ scripts/get_maintainer.py --release-to
Joakim Bech6e53df72019-09-18 16:57:23 +0200115
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200116 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 Bech6e53df72019-09-18 16:57:23 +0200122 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 Forissiera42d1c12019-10-15 09:45:34 +0200132 5. Send a follow up email to all maintainers to let them know that there is
Joakim Bech6e53df72019-09-18 16:57:23 +0200133 a release tag ready to be tested on their devices for the platforms that
134 they are maintaining.
135
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200136 6. In case major regressions are found, then fix those and create a another
Joakim Bech6e53df72019-09-18 16:57:23 +0200137 release candidate tag (i.e., repeat step 3 and 4 until there are no
138 remaining issues left).
139
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200140 7. On release day: Update CHANGELOG.md_ see this `changelog example`_ to see
Joakim Bech6e53df72019-09-18 16:57:23 +0200141 how that should look like.
142
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200143 8. Collect all tags (``Tested-By`` etc) from maintainers and use those in
Joakim Bech6e53df72019-09-18 16:57:23 +0200144 the commit message, for an example see this `commit example`_.
145
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200146 9. Create a release tag (annotated tag, i.e., ``git tag -a 3.x.y -m
Joakim Bech6e53df72019-09-18 16:57:23 +0200147 "3.x.y"``) in the following gits ``optee_*`` and ``build.git``.
148
149 .. hint::
150
Jerome Forissierfe882612020-01-28 10:48:46 +0100151 You can use the same steps as in step 4, when creating the tags.
Joakim Bech6e53df72019-09-18 16:57:23 +0200152
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200153 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 Bech6e53df72019-09-18 16:57:23 +0200156
157
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200158 11. Update all :ref:`manifest` XML-files in the :ref:`manifest` git, so they
Joakim Bech6e53df72019-09-18 16:57:23 +0200159 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 Forissierc8f60612020-01-28 10:51:27 +0100172 $ git tag -a $VER -m $VER
Joakim Bech6e53df72019-09-18 16:57:23 +0200173 $ git push upstream tag $VER
174
Jerome Forissiera42d1c12019-10-15 09:45:34 +0200175 12. Send a last email to maintainers and other stakeholders telling that the
Joakim Bech6e53df72019-09-18 16:57:23 +0200176 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 Forissiera42d1c12019-10-15 09:45:34 +0200187.. _mk/config.mk: https://github.com/OP-TEE/optee_os/blob/master/mk/config.mk