openharmony/release-management
1
0
Fork 0
mirror of https://gitee.com/openharmony/release-management synced 2024-11-27 08:40:24 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

!57 翻译完成：新增 OpenHarmony生命周期发布公告 英文版

Browse Source 
Merge pull request !57 from wusongqing/master
This commit is contained in:
mamingshuai 2023-04-06 10:07:18 +00:00 committed by Gitee
commit 24c9466434
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
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.