Code repository branching model

Default branches

  • main or master -> used for the latest released version of the code

Version numbers

We use semantic versioning to define the version numbers on all our product projects.

Creation of new branches

Use branch name prefixes to help identify the purpose of the branches and facilitate code review.

We use the following branch prefixes:

  • release/ for the next releases of the project.
  • feature/ for new features or changes on existing features
  • bugfix/ for bug fixes on development code

Branches for new feature/ or bugfix/ are always created from the next release/ branch version.

If the new feature is a major feature, we might need to create a new release/ branch and bump the middle (minor) digit in the version number (eg. 1.4.4 ➝ 1.5.0) and then create the new feature/ branch from that.

Pull Requests (PR)

When work on a feature/ or bugfix/ branch is completed, create a new Pull Request to integrate the code into the next version release/ branch.

Remember to create the PR to be merged into the lowest release/<version> branch available.

Usually, there is only one release/<version> branch available at a time, but more two or more might be available at the same time if we are postponing the release of a brand new feature, which, according to semantic versioning, requires a change to the minor|middle digit of the version number.

For example: We might have the branches release/1.4.6 available for patches and new compatibility fixes, and release/1.5.0 available for brand new features. You should create new PR to be merged into release/1.4.6, except when you are working on a brand new feature.

Once you are finished creating the PR, review all your code changes and make the necessary adjustments. After that, assign the related task on ClickUp to the project lead developer. They will then review the code, add comments, ask for changes if needed, and then merge the PR code when everything is ready.

Releases

Release versions (eg. 2.0.1, 2.0.2-dev-1) are created only on the main branch and tested on the a staging site of the project before merging the code into the `main` branch.

If the repository makes use of a production branch, after testing the new release it will be merged to the production branch via a pull request. The production branch is updated only by merging with pull requests after the full version is tested on a staging site.