How release candidates are tested and published, and the Gitflow-based branching model used across the 5G-MAG Reference Tools repositories.
Looking for how to raise issues, fork, or open a pull request instead? See How to Contribute.
Release Process
The status of the different software releases can be found on the Community page.
Testing release candidates
Availability of a RC for testing is announced in the Google Group and/or during the 5G-MAG Developers Calls. Feedback can be provided via issues during the testing period. If there are blocking issues, these will be fixed and a new release candidate will be created.
If after the testing period no issues have been found which block the release, a release will be created and announced.
Git Branching strategy
We are using a slightly modified version of Gitflow as a branching model. A detailed introduction to Gitflow can be found in this Introduction to Gitflow.
The table below summarises the branch types; each is described in detail after it.
| Branch type | Created from | Merged into | Purpose |
|---|---|---|---|
| Feature | development | development | Implement a new feature |
| Bugfix | development | development | Fix a non-critical bug |
| Release | development | main | Prepare and publish a release |
| Hotfix | main | main and development | Patch a critical error in a production release |
Main branch
The main branch stores the official release history. The current version of the main branch always stores the latest release.
Development branch
The development branch serves as the integration branch for new feature and bugfix branches. It reflects the latest stable changes in the current development cycle.
Feature branches
Each new feature is implemented in a separate feature branch. Feature branches use development as their parent branch. When a feature is completed the respective branch gets merged back into development.
A feature branch is created the following way:
git checkout development
git checkout -b feature/newfeature
Release branches
Once the development branch has acquired enough features and bugfixes for a release, a release candidate branch is created based on the current version of the development branch. For details on the release procedure please refer to the release procedure documentation in the relevant repository.
The release candidate always includes a version number and is created in the following way:
git checkout development
git checkout -b RC-1.2.0
Once a release candidate is approved the respective branch is merged into the main branch.
Bugfix branches
Similar to feature branches, the bugfix branches are created directly from development. In contrast to hotfixes, bugfixes are not considered critical and do not require a fast new release. Bugfix branches are created the following way:
git checkout development
git checkout -b bugfix/newbugfix
Hotfix branches
Hotfix branches are used to quickly patch production releases in case of critical errors. Hotfix branches are created directly from main and merged back into main and development as soon as they are completed. Once the hotfix is applied a new release shall be created.
git checkout main
git checkout -b hotfix/newhotfix
Cloning a repository with a specific branch
It is also possible to clone a repository and specify the target branch directly:
git clone -b <branchname> <remote-repo-url>