New versions of OP-TEE are released four times a year, i.e., quarterly releases.


The changelog is stored in the optee_os git ( There you can see what has been done between the different releases in terms of commits as well as pull requests.

Versioning schema

OP-TEE follows Semantic Versioning 2.0.0. What that means in practice is well described at the link just shown.

Release procedure

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.


Short version of the OP-TEE release procedure
When (Tminus) Action Example
3w Create release pull request PR#3099
3w Inform maintainers about upcoming release  
1w Increment the revision number in mk/ CFG_OPTEE_REVISION_MAJOR ?= 3 CFG_OPTEE_REVISION_MINOR ?= x
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 example
Release day Collect/merge Tested-By tags commit example
Release day Create release tag in optee_* + build.git git tag -a 3.x.y -m “3.x.y”
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.  

Long version

  1. Create a “release pull request” at GitHub ought to collect Tested-By tags from various maintainers. As an example, see PR#3099.

  2. 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/ --release-to
  3. Increment the revision number in mk/ CFG_OPTEE_REVISION_MAJOR and CFG_OPTEE_REVISION_MINOR. These values are made available to TAs and to the Normal World driver at boot time.

  4. 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 optee_* and 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
  5. 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.

  6. 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).

  7. On release day: Update see this changelog example to see how that should look like.

  8. Collect all tags (Tested-By etc) from maintainers and use those in the commit message, for an example see this commit example.

  9. Create a release tag (annotated tag, i.e., git tag -a 3.x.y -m "3.x.y") in the following gits optee_* and build.git.


    You can use the same steps as in step 4, when creating the tags.

  10. Create a new branch in manifest from master where the name corresponds to the release you are preparing. I.e., git checkout -b 3.x.y origin/master.

  11. 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 script. Now it is also time to push the new branch and tag it. Example:

$ export VER=3.x.y
$ cd manifest
$ ./ -o -r $VER
$ git diff  # make sure everything looks good
$ git commit -a -m "OP-TEE $VER stable"
$ git remote add upstream
$ git push upstream
$ git tag -a $VER -m $VER
$ git push upstream tag $VER
  1. Send a last email to maintainers and other stakeholders telling that the release has been completed.