Repository Management

This page outlines aspects of repository management including our branching strategy.

Development

We follow a standard pattern of trunk and branch for development. The definitive history of the source code is maintained on a trunk branch called "master" in the metomi/fab repository. Changes are made on branches of this trunk made on the developer's repository clone.

In order to get a development branch merged to trunk a "Pull Request" is raised. Once the pull request is approved we use a "squash merge" to bring the change to trunk.

Version numbering

For releases we follow the standard major.minor.patch version numbering scheme.

• Changes in major number imply an API breakage.
• Changes in minor number imply new functionality.
• Changes in patch number imply bug fixes.

Release Branches

Releases are made from a release branch. This allows continued, uninterupted, development on trunk.

Major and minor releases cause a fresh release branch to be made, picking up the new features added to trunk since the previous major or minor release. Bug fixes are applied to trunk and back ported to the current release branch. Patch releases are then made from that release branch by cherry picking changes onto the branch.