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

For more details read the GitLab Flow Best Practices, please.

Building Release-Candidates

  1. Build a new release branch from main and name it releases/v<Major.Minor>

  2. check the version in .version file

  3. Tag the version with git tag v<Major.Minor.Patch>-rc<No> -m "Version <Major.Minor.Patch>-rc<No>

  4. Push tag to remote git push --tags

  5. Build Container

    make RC=<No> clean addon-rc rc
    

Building a Release

  1. Update Changelog and merge this to the main and release branch

  2. check the version in .version file and merge this to the main and release branch

  3. Checkout the release branch releases/v<Major.Minor>

  4. Tag the version with git tag v<Major.Minor.Patch>-rel -m "Version <Major.Minor.Patch>-rel"

  5. Push tag to remote git push --tags

  6. Build container

    make clean addon-rel rel