Release cycle
Terminology
The major versions (referred to as a release) occur twice per year: the last weeks of March and September (previously quaterly with an additional release in June and December).
The versions are prefixed with full year and quarter number ( |
|||
A version branch contains the code included in that release; for example, the |
|||
A feature branch contains all of the code of the specific version; for example, the |
|||
A release is a git tag on the latest stable commit on a version branch.
The git tag follows the pattern of |
|||
A patch release is a git tag on the latest stable commit on an already released version branch.
The git tag follows the pattern of
|
|||
A development release is an unstable release of features currently in the development and planned for the upcoming release.
The git tag follows the pattern of |
|||
A release candidate is a git tag on the latest commit on a version branch.
Release candidate indicates the branch stability is getting ready for a major release.
The git tag follows the pattern of |
|||
The term version may refer to ether one of the release, feature, version branch, patch release, or release candidate terms |
Git(Hub)
All of the development on Corteza is powered by Git and GitHub (GH). To make development consistent and easy to follow, we’ve put in place a few rules the contributors need to follow.
Cleanup and rebase feature branches
Before the feature branch is merged into the release branch, it needs to be rebased with the release branch to reduce the diff size. We recommend that you rebase regularly to reduce the potential merge conflicts.
Additionally, use the interactive rebase to reconstruct the git history that your feature branch introduces to make it cleaner and shorter. History should tell a story. Sometimes it’s easier to recreate the entire commit history once you’ve finished the first version of the feature.
Merging the branch
If the source branch is small (a handful of commits), use a fast-forward merge (the merge without the merge commit). If the source branch introduces significant changes (it introduces new features), use a non fast-forward merge (the merge with the merge commit).
|
Remove the branch after it is merged. Only the core contributors are sometimes allowed to forget to do so. |
Rename delayed feature branches
If a feature is delayed to the next release, rename the branch to match that release branch.
For example, if the 2020.12.x-feature-foo gets delayed to the 2021.3.x, the feature branch needs to be renamed to 2021.3.x-feature-foo.
Avoid committing directly to the version branch
Minor changes (such as a hotfix) can skip the entire pull request process. Larger changes should always go through the pull request process.
Back-porting
Bug fixes or improvements that also apply to the already released versions cherry-pick the commits to those version branches. When back-porting, condense the change to a single commit with a clear and descriptive commit message.
In-progress version branch
Whenever a release occurs and the next set of version branches is created, the default GitHub branch is moved to the newly created version branch. This makes it easier for new contributors while letting us showcase the latest and greatest version.
The in-progress version branch is expected to be rebased with the current release branch to defer the branch diversion because of post-release patches. The rebasing usually stops when new features are being applied.