(This document assumes you are already familiar with Cobalt Versioning practices.)
The Cobalt project uses git branches for two main purposes:
masterbranch developers from risky or disruptive work.
A “Cobalt release” is an official, tested version of Cobalt that is intended to be deployable to production. We branch for releases to allow development to continue on the
master branch while stabilizing and finalizing a set of sources for release.
Feature work is done in the
Once all feature work is completed, a release branch is created. The branch will be named “[Feature Year].[Purpose].[Update Number]+”. Note that while very similar to the structure of the Cobalt version, it features a
+ symbol at the end, indicating that the branch may eventually contain multiple release updates, all greater than or equal to the specified update number. In particular, a single branch may host multiple releases/updates. Should another release branch be cut from master with a pre-existing (feature year, purpose) pair, the new branch will have an update number equivalent to the most recently released update number, plus one. Note that we expect it to be rare that we will need a branch other than the
An example release branch name is
An RC announcement will be made to firstname.lastname@example.org.
Note that a release branch implies that code on that branch is being stabilized, not that it is ready for release. Versions of Cobalt that are ready for release will have a dedicated
*.stable branch pointing to them, and will be discussed later.
As bugs are discovered and feedback received from partners, fixes will be cherry-picked into the release candidate branch. These cherry-picks should not be considered stable again until the
*.stable branch is updated.
As time goes on, the number of cherry-picks will decrease in number and scope.
Once a commit on the branch is deemed to be feature-complete and stable, it will be tagged with the current version for that branch, and the version will be incremented for all subsequent commits. A special branch that acts more like a “moving tag” named “[Feature Year].[Purpose].stable” will be created to point to the newly released version. Should a subsequent update be made for the given feature year and purpose, the
*.stable branch will be updated to point to the newest update.
An example stable branch name is
Some example release tags are:
A release announcement will be made to email@example.com.
If a set of work is deemed to be particularly risky or disruptive, or if a serious contributor wants a sandbox to prepare an extensive patch, a work branch may be created to facilitate such development.
Work branch names are of the form
<topic> is the purpose for which the branch was created. Work branches are generally in use by a specific and limited set of people, and may disappear at any time.
Older branches have been following different branch naming schemes, and for a description of those schemes, the version of this branching.md file within those branches should be consulted.