Skip to content
This repository was archived by the owner on Jan 26, 2024. It is now read-only.

Commit 2328ec8

Browse files
authored
Merge pull request #2475 from patzick/feature/release-cycle-in-branches
[DOCS] explain release cycle in branches
2 parents 4874488 + f850421 commit 2328ec8

File tree

4 files changed

+29
-3
lines changed

4 files changed

+29
-3
lines changed
23.4 KB
Loading
55.1 KB
Loading
52.5 KB
Loading

docs/guide/basics/release-cycle.md

Lines changed: 29 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
This document describes how Vue Storefront code versions are released. You'll learn how the release process looks like, what are the acceptance criteria, what is our git flow and which branch to use as a stable one.
44

5-
# How Vue Storefront versions are released
5+
## How Vue Storefront versions are released
66

77
From version 1.9 we release each of VSF versions in two phases
88
- **Release Candidate phase (RC)** also called "feature version". This version contains all the new features, improvements and additions to the API along with minor bugfixes. New features and additions are merged and released **only** during this phase. The API of features introduced during this phase may slightly change.
@@ -12,9 +12,35 @@ So assuming next version is 1.x the two-month cycle will look as following:
1212
- v1.x-RC.y - unstable version with cutting-edge features ready to test and feedback
1313
- v1.x.y - stable version of the software **ready for production use**.
1414

15-
# How new features are merged
15+
## How new features are merged
1616

1717
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.
1919
During the stabilization phase new features are merged to develop branch and will be merged on next `RC` phase.
2020

21+
## Release cycle flow
22+
23+
### 1. Development phase
24+
25+
The first phase of cycle we're mostly focusing on features and improvements. Branches in that phase should be created from actual `develop`, also PRs should be pointed to this branch. Changes merged to `develop` are available to test on https://test.storefrontcloud.io
26+
27+
![Development phase](./assets/release-cycle-1.png)
28+
29+
### 2. Release Candidate phase
30+
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+
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 `release/vx.y` and should not contain features at this point - only improvements for current release.
34+
After merging a set of bugfixes and improvements into `release/*` branch, it needs to be tagged as the next RC version and merged into the `develop` branch, to update it.
35+
36+
![Release Candidate phase](./assets/release-cycle-2.png)
37+
38+
### 3. Release phase
39+
40+
When RC version is stable, then release branch is merged into `master` and tagged as next stable version (example `v1.9.0`). After that currently merged release branch is deleted and starts new development phase. If some critical bug is discovered on current stable version, then new hotfix (for example `hotfix/v1.9.1`, following [Semantic Versioning rules](https://semver.org/)) branch should be created from actual `master`. After merging and testing hotfixes, this branch (like release branch before) is merged into `master` and tagged following [Semantic Versioning rules](https://semver.org/).
41+
42+
![Release phase](./assets/release-cycle-3.png)
43+
44+
### Summary
45+
46+
Important thing to notice is that this releasing cycle ensures stable and reliable Storefront releases. Phases are also not blocking new features - you can develop new features on any phase, but it should be merged only to `develop` branch and go through whole cycle.

0 commit comments

Comments
 (0)