1Release Cadence and Process
2===========================
3
4Project Release Cadence
5-----------------------
6
7The project aims to do a release once every 6 months around April and November
8time and are listed in the :ref:`releases/index:Future release plans`.
9The releases are to be performed and tagged on a dedicated release branch.
10The release process is initiated by an announcement in
11`TF-M mailing list <https://lists.trustedfirmware.org/mailman3/lists/tf-m.lists.trustedfirmware.org/>`_
12and followed by the creation of a release branch.
13Normal development on the main branch is not blocked and can be continued.
14The testing will be performed on release candidates and depending on
15issues found, additional candidates may be created to fix and retest the issues.
16
17:doc:`The Platform owners </contributing/maintainers>` are expected to
18verify their platforms and confirm the correct operations or provide fixes
19in a timely manner to include in the release. The release notes will list
20all verified platforms. The platforms in Trusted Firmware OpenCI is
21automatically tested and any issues found shall be fixed.
22
23After the final tag, the changes from the release branch will be back ported
24to main branch.
25
26.. uml::
27
28    @startuml
29        concise "main branch" as main
30        concise "release branch v1.1.x" as rel1
31        concise "release branch v1.2.x" as rel2
32
33    @main
34        -3 is development
35        @0 <-> @8 : release cadence: ~6 months
36
37    @rel1
38        0 is rc1
39        main -> rel1 : start
40        +1 is rc2
41        +1 is v1.1.0
42        +1 is {-}
43        rel1 -> main : back port
44        +1 is v1.1.1 #pink
45        +1 is {-}
46        rel1 -> main : cherry-pick
47        +3 is {hidden}
48
49    @rel2
50        8 is rc1
51        main -> rel2 : start
52        +1 is v1.2.0
53        +1 is {-}
54
55        rel2 -> main : back port
56
57        @0 <-> @3 : release process
58        @4 <-> @5 : hotfix
59
60    @enduml
61
62Although this document specifies the release cadence, this does not preclude
63an adhoc release for specific project requirements.
64
65.. note::
66  When a new release starts the previous release branch obsoletes and is
67  a subject for removal as shown for `v1.1.x` on the diagram above.
68  At any moment only the latest release branch is maintained.
69  The release tags will point to a commit in detached head state.
70
71Release Version Scheme
72----------------------
73
74Trusted Firmware-M uses a semantic versioning scheme. A version number is
75compiled as a dot separated set of numbers:
76
77**TF-Mv<MAJOR>.<MINOR>.<HOTFIX>**
78
79- <MAJOR>: Major release version for significant feature and API changes.
80- <MINOR>: Minor release version for incremental features and API changes.
81- <HOTFIX>: Used only for backporting **critical bug fix/security patches**.
82
83--------------
84
85*Copyright (c) 2020-2023, Arm Limited. All rights reserved.*
86