openharmony/release-management
1
0
Fork 0
mirror of https://gitee.com/openharmony/release-management synced 2025-02-17 04:49:30 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

added openHarmony-version-lifecycle-management EN

Browse Source 
Signed-off-by: Gloria <wusongqing@huawei.com>
This commit is contained in:
Gloria 2023-04-06 17:40:40 +08:00
parent 405a2335a2
commit 6e07f88eeb
2 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
figures/lifecycle-en.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

21
openHarmony-version-lifecycle-management.md Normal file
View File

@ -0,0 +1,21 @@
# OpenHarmony Version Lifecycle Management
The OpenHarmony community regularly releases LTS and Release branches and provides maintenance and technical support based on the OpenHarmony lifecycle management policy.
**Release**: A Release branch is a stable branch released in the community. A Release branch can be released only after centralized compilation, build, integration test, and review. Then it enters the maintenance phase.
**LTS**: A **Release** branch can be changed to a long-term support (LTS) branch after being approved by the community based on its application scope and quality. The maintenance lifecycle of an LTS branch is longer than that of a Release branch.
![lifecycle](figures/lifecycle-en.jpg)
#### Lifecycle management policy
1. The lifecycle of a Release branch is two years (1+1).
2. The lifecycle of an LTS branch is 3.5 years (2 + 1.5).
3. Proactive maintenance period: During this period, the community routinely plans and maintains label versions, fixes defect and security vulnerabilities, incorporates other necessary modifications, and ensure that branches are stable and available.
4. Passive maintenance period: During this period, the community no longer plans or releases label versions. It only fixes major or higher security vulnerabilities and defects.
5. The end of the lifecycle of a branch will be made public by email and bulletin.