提交 8edb5863 编写于 作者: G Gloria

Update docs against 13711+13920

Signed-off-by: wusongqing<wusongqing@huawei.com>
上级 459882dd
......@@ -4,8 +4,6 @@
To ensure smooth version evolution and continuous stability and reliability of historical versions, the OpenHarmony community periodically pulls branches such as Long Term Support (LTS), Release, and Beta from Master and manages them based on the OpenHarmony lifecycle definition.
![1.png](figures/1.png)
### Master
......@@ -13,11 +11,11 @@ Master is the main branch in the OpenHarmony community, to which code updates of
### LTS
LTS is a branch pulled from Master in the OpenHarmony community in the third quarter of each year. This branch is compiled, built, and tested in a centralized manner, and finally reviewed and released by the community.
LTS is a branch pulled from Master in the OpenHarmony community by year. This branch is compiled, built, and tested in a centralized manner, and finally reviewed and released by the community.
### Release
Release is a branch pulled from Master in the OpenHarmony community in the first quarter of each year. This branch is compiled, built, and tested in a centralized manner, and finally reviewed and released by the community. A Release branch has the same release requirements but a shorter maintenance period when compared with an LTS branch.
Release is a stable branch released in the OpenHarmony community. This branch is compiled, built, and tested in a centralized manner, and finally reviewed and released by the community. A Release branch has the same release requirements but a shorter maintenance period when compared with an LTS branch.
### Beta
......@@ -27,6 +25,16 @@ Beta is a branch pulled from Master in the OpenHarmony community irregularly. Th
A tag version is a stable and reliable version created by applying patches to an LTS or a Release branch, with the purpose of fixing individual bugs, security vulnerabilities, and other necessary adaptation modifications.
### Commands for Downloading Branches
| Branch | Download Command (repo + https) | Download Command (repo + ssh) |
| ------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 1.0.1-Release | repo init -u https://gitee.com/openharmony/manifest -b OpenHarmony_1.0.1_release -m default.xml --no-repo-verify<br>repo sync -c<br>repo forall -c 'git lfs pull' | repo init -u git@gitee.com:openharmony/manifest.git -b OpenHarmony-3.1-Release -m default.xml --no-repo-verify<br>repo sync -c<br>repo forall -c 'git lfs pull' |
| 3.0-LTS | repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-3.0-LTS --no-repo-verify<br>repo sync -c<br>repo forall -c 'git lfs pull' | repo init -u git@gitee.com:openharmony/manifest.git -b OpenHarmony-3.0-LTS --no-repo-verify<br>repo sync -c<br>repo forall -c 'git lfs pull' |
| 3.1-Release | repo init -u git@gitee.com:openharmony/manifest.git -b OpenHarmony-3.1-Release -m default.xml --no-repo-verify<br>repo sync -c<br>repo forall -c 'git lfs pull' | repo init -u git@gitee.com:openharmony/manifest.git -b OpenHarmony-3.1-Release -m default.xml --no-repo-verify<br>repo sync -c<br>repo forall -c 'git lfs pull' |
## Maintenance Policies
### Lifecycle Policies
......@@ -35,11 +43,11 @@ OpenHarmony provides lifecycle management services for LTS and Release branches
#### Release -> Stop proactive maintenance
The Release SIG periodically makes and maintains tag version plans to resolve individual bugs, security vulnerabilities, and other major issues to ensure continuously stable and available branches.
The Release SIG periodically makes and maintains tag version plans to resolve individual bugs, security vulnerabilities, and other major issues to ensure continuously stable and available branches.
#### Stop proactive maintenance -> Stop maintenance
The Release SIG no longer proactively plans and releases tag versions. It only fixes security vulnerabilities and major defects in corresponding branches.
The Release SIG no longer proactively plans and releases tag versions. It only fixes security vulnerabilities and major defects in corresponding branches.
### LTS and Release Maintenance Policies
......
# Mappings Between Label Versions and System Versions
A system version consists of the operating system name and software version number, separated by a hyphen (-). The software version number contains four digits, representing the major, minor, feature, and build versions in sequence. A system version can have a maximum of 64 characters (spaces not allowed) and can be obtained by running the API **GetOsFullName()**.
The label versions released in the OpenHarmony community, for example, 1.1.x, 3.0.x, and 3.1.x, use 3-digit version numbers. To avoid troubles, the following table lists the mappings between the label versions released in the community and their system versions.
## Mappings between label versions and system versions
| Label Version | Small/Mini System Version | Standard System Version | Remarks |
| -------------------------- | -------------------- | -------------------- | -------------------------- |
| OpenHarmony_release_v1.1.0 | NA | NA | No system version is defined. |
| OpenHarmony-v1.1.1-LTS | NA | NA | No system version is defined. |
| OpenHarmony-v1.1.2-LTS | NA | NA | No system version is defined. |
| OpenHarmony-v1.1.3-LTS | NA | NA | No system version is defined. |
| OpenHarmony-v1.1.4-LTS | NA | NA | No system version is defined. |
| OpenHarmony-v1.1.5-LTS | NA | NA | No system version is defined. |
| OpenHarmony-v3.0-LTS | OpenHarmony-3.0.0.0 | OpenHarmony-3.0.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.0.1-LTS | OpenHarmony-3.0.0.0 | OpenHarmony-3.0.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.0.2-LTS | OpenHarmony-3.0.0.0 | OpenHarmony-3.0.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.0.3-LTS | OpenHarmony-3.0.0.0 | OpenHarmony-3.0.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.0.5-LTS | OpenHarmony-3.0.0.0 | OpenHarmony-3.0.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.0.6-LTS | OpenHarmony-3.0.0.0 | OpenHarmony-3.0.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.0.7-LTS | OpenHarmony-3.0.7.2 | OpenHarmony-3.0.7.2 | NA |
| OpenHarmony-v3.1-Release | OpenHarmony-1.0.1.0 | OpenHarmony-2.2.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.1.1-Release | OpenHarmony-1.0.1.0 | OpenHarmony-2.2.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.1.2-Release | OpenHarmony-1.0.1.0 | OpenHarmony-2.2.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.1.3-Release | OpenHarmony-3.1.8.5 | OpenHarmony-2.2.0.0 | The **OsFullName** field is not modified.|
| OpenHarmony-v3.1.4-Release | OpenHarmony-3.1.9.6 | OpenHarmony-3.1.9.6 | NA |
| OpenHarmony-v3.1.5-Release | OpenHarmony-3.1.11.5 | OpenHarmony-3.1.11.5 | NA |
## Changing System Versions
### For 1.0.x, 3.0.x, and 3.1.x
Integration configuration is unavailable for 1.0.x, 3.0.x, and 3.1.x in the community, so you need to modify the configuration in different files for small or mini systems and standard systems.
For the small or mini system, the **OsFullName** field is in the following file: startup_syspara_lite/ frameworks / parameter / src / parameter_common.c
For the standard system, the **OsFullName** field is in the following file: startup_syspara_lite/ interfaces / innerkits / native / syspara / src / sysversion.c
Change the **static const int MAJOR_VERSION**, **static const int SENIOR_VERSION**, **static const int FEATURE_VERSION**, and **static const int BUILD_VERSION** fields to the corresponding system versions.
### For 3.2.x and Later Versions
Change the **const.ohos.fullname** field in the file **startup_init_lite/ services / etc_lite / param / ohos_const / ohos.para**
to the corresponding system version.
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册