New versions of OP-TEE are released four times a year, i.e., quarterly releases.
Starting from version 3.10.0 we track the old and also show the releases being planned for the future in the table below. The dates will tell whether it is an old, upcoming or future release.
OP-TEE follows Semantic Versioning 2.0.0. What that means in practice is well described at the link just shown.
There are certain steps that needs to be done when making a release. This checklist here serves as guidance to the one in charge of making a new release. Roughly start with this 2-3 weeks before the targeted release date.
|3w||Create release pull request||PR#3099|
|3w||Inform maintainers about upcoming release|
|1w||Increment the revision number in mk/config.mk||
|1w||Create release candidate tag in optee_* + build.git||git tag -a 3.x.y-rc1 -m “3.x.y-rc1”|
|1w||Let maintainers know about the release candidate tag|
|1w||Test platform builds / devices|
|Release day||Update CHANGELOG.md||changelog example|
|Release day||Create release tag in optee_* + build.git + linux.git||
git tag -a 3.x.y -m “3.x.y”
git tag -a optee-3.x.y -m “optee-3.x.y” # (Linux)
|Release day||Create release branch in manifest||git checkout -b 3.x.y origin/master|
|Release day||Update manifest XML-files||3.6.0 stable|
|Release day||Inform maintainers and stakeholder that release has been completed.|
Create a “release pull request” at GitHub ought to collect
Tested-Bytags from various maintainers. As an example, see PR#3099.
Send email to all maintainers to let them know about the upcoming release. The addresses to the maintainers can be found in the MAINTAINERS file.
With this command you will get all email addresses$ scripts/get_maintainer.py --release-to
Increment the revision number in mk/config.mk:
CFG_OPTEE_REVISION_MINOR. These values are made available to TAs and to the Normal World driver at boot time.
Create a release candidate (RC) tag (annotated tag, i.e.,
git tag -a 3.x.y-rc1 -m "3.x.y-rc1") in the following gits
build.git. One way to do it is like this$ export VER=3.x.y-rc1 $ for d in optee* build; do ( cd $d; git tag -a $VER -m $VER ); done $ for d in optee* build; do ( cd $d; git push origin $VER ); done
Send a follow up email to all maintainers to let them know that there is a release tag ready to be tested on their devices for the platforms that they are maintaining.
In case major regressions are found, then fix those and create a another release candidate tag (i.e., repeat step 3 and 4 until there are no remaining issues left).
Collect all tags (
Tested-Byetc) from maintainers and use those in the commit message, for an example see this commit example.
Create a release tag (annotated tag, i.e.,
git tag -a 3.x.y -m "3.x.y") in the following gits
build.git. Tag the tip of the
linux.git, the name of the tag has to be prefixed with
optee-to avoid confusions. For instance:
git tag -a optee-3.x.y -m "optee-3.x.y".
You can use the same steps as in step 4, when creating the tags.
Create a new branch in manifest from
masterwhere the name corresponds to the release you are preparing. I.e.,
git checkout -b 3.x.y origin/master.
Update all manifest XML-files in the manifest git, so they refer to the tag in the release we are working with (see 3.6.0 stable commit as an example). This can be done with the make_stable.sh script. Now it is also time to push the new branch and tag it. Example:$ export VER=3.x.y $ cd manifest $ ./make_stable.sh -o -r $VER $ git diff # make sure everything looks good $ git commit -a -m "OP-TEE $VER stable" $ git remote add upstream firstname.lastname@example.org:OP-TEE/manifest $ git push upstream $ git tag -a $VER -m $VER $ git push upstream tag $VER
- Send a last email to maintainers and other stakeholders telling that the release has been completed.