dev branch flow - s-allius/tsun-gen3-proxy GitHub Wiki
Git Branch Strategy
We use the well known GitLab Flow as branching and merching strategy. This means:
- our main branch is always "production ready"
- we don't push directly into main
- we use feature branches for bugfix and feature development
- for releases we use release branches. The naming is
releases/v<Major.Minor>
- release will be tagged with
v<Major.Minor>.0
- release update will be tagged with
v<Major.Minor.UpdateNumber>
- no Rebase or Squash merges into release branches
- release will be tagged with
For more details read the GitLab Flow Best Practices, please.
Building Release-Candidates
-
Build a new release branch from main and name it
releases/v<Major.Minor>
-
check the version in
.version
file -
Tag the version with
git tag v<Major.Minor.Patch>-rc<No> -m "Version <Major.Minor.Patch>-rc<No>
-
Push tag to remote
git push --tags
-
Build Container
make RC=<No> clean addon-rc rc
Building a Release
-
Update Changelog and merge this to the main and release branch
-
check the version in
.version
file and merge this to the main and release branch -
Checkout the release branch
releases/v<Major.Minor>
-
Tag the version with
git tag v<Major.Minor.Patch>-rel -m "Version <Major.Minor.Patch>-rel"
-
Push tag to remote
git push --tags
-
Build container
make clean addon-rel rel