This page describes the branches in the Forseti repository and how they’re used and managed.
Following are the branches that the Forseti Security project team uses for developing, creating releases, and building the website:
dev: The currently active development branch.master: The latest Forseti release suitable for deployment to production.forsetisecurity.org-dev: The currently active development branch of the
Forseti website.forsetisecurity.org: The latest deployed Forseti website.The dev branch is the starting point where you can create a new PR.
Although there are unit tests, the dev branch is still considered to be
unreliable because it can change before it’s merged into the master
branch.
The master branch is checkpointed code from the dev branch that
has passed QA and integration testing. The master branch is considered
to be stable and suitable for production use.
Branches will be created to develop the next-generation versions of Forseti Security. These next-generation branches will be prefixed with a version number.
Typically, the team will begin with an N.N-dev branch. After the code
is developed so it’s suitable for early testing, an Early Access Phase (EAP)
branch will be created, like N.N-eap1.
After the EAP is complete, a Release Candidate (RC) will be created, like
N.N-rc1. After all testing requirements are satisfied,
the team will merge the completed code into N.N-dev, then into
N.N-master, then into dev, and finally master.
Following is an example of this workflow for future versions:
3.0-dev: A daily development branch.3.0-eap1: A branch used for Early Access testing.3.0-rc1: A possible release candidate.3.0-rc2: A second release candidate with additional changes.master: The final released version of v2.0.Before launching a new version, the existing dev and master will be moved
and renamed as (N-1).0-dev and (N-1).0-master. Existing N.N-dev
will be moved and renamed to dev. A new master branch will be created from
dev branch. This is so that the dev and master branches are always
maintained as the canonical branches, and all the commit histories and tags
are retained.
For example, when a future version 3.0 is ready to be launched:
# Change the existing dev branch to be the deprecated development branch.
dev --> 2.0-dev
# Change the existing master branch to be the deprecated release branch.
master --> 2.0-master
# Change the new version's dev branch to be the active development branch.
3.0-dev --> dev
# Create a new active release branch from the active release branch.
Other active branches in the Forseti repo are those created by other developers to contribute to Forseti. You can generally disregard any branches that aren’t described above.
Forseti version number scheme follows the Semantic Versioning defined by semver.org,
and are denoted as X.Y.Z. For example:
X signifies MAJOR changes, when architecture has changed.
Y signifies MINOR changes, when new features are added, along with bug fixes.
Z signifies PATCH changes, when only bug fixes are added.
The process below outlines how minor new X.Y.Z point versions are managed.
When a new point version is ready to be released, a new x.Y.z or x.y.Z
version will be created from the dev branch.
The release branch will undergo functional and integration testing. Any bugs found are fixed as follows:
A new feature branch is created from the release branch.
A code review is completed.
The bug fix is merged back into the release branch.
When the release branch is fully qualified, the branch is merged into
the master and dev branch.
After the release branch is merged, it’s deleted.