You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 26, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: docs/guide/basics/release-cycle.md
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ So assuming next version is 1.x the two-month cycle will look as following:
15
15
## How new features are merged
16
16
17
17
During RC features Pull Request with new features after feedback and acceptance are normally merged to `develop` branch.
18
-
After entering the Stabilization Phase we are tagging current develop branch, creating a `RC-x` (where `x` is a number of current version) branch from it and working on stabilization there.
18
+
After entering the Stabilization Phase we are tagging current develop branch, creating a `release/x` (where `x` is a number of current version) branch from it and working on stabilization there.
19
19
During the stabilization phase new features are merged to develop branch and will be merged on next `RC` phase.
20
20
21
21
## Release cycle flow
@@ -28,9 +28,9 @@ The first phase of cycle we're mostly focusing on features and improvements. Bra
28
28
29
29
### 2. Release Candidate phase
30
30
31
-
At some point, when milestone for next minor versions is completed, we're creating new branch from `develop` called `rc-x.y` (example: `rc-1.9`).
31
+
At some point, when milestone for next minor versions is completed, we're creating new branch from `develop` called `release/vx.y` (example: `release/v1.9`).
32
32
After that new branch is tagged as first RC for version (example `v1.9.0-rc.1`). Then it's ready for testing by community.
33
-
During tests, feedback and stabilization there could be multiple Release Candidate versions on this branch. When improvement is made on this phase, then branch should be created from actual `rc-x.y` and should not contain features at this point - only improvements for current release.
33
+
During tests, feedback and stabilization there could be multiple Release Candidate versions on this branch. When improvement is made on this phase, then branch should be created from actual `release/vx.y` and should not contain features at this point - only improvements for current release.
34
34
When release branch is updated, then should `develop` should be synchronized with it.
0 commit comments