OpenAVB Branch Policy

Branch Overview

There are two permanent branches, master and open-avb-next. The permanent branches are supplemented by three different kinds of short-term temporary branches: release branches, feature branches, and hotfix branches.

Temporary branches must be merged to their final destinations with the --no-ff flag to ensure that the history of the branches is preserved in the repository. After this final merge, they should be deleted.

master Branch

The master branch represents the latest production-ready code. This is where end users should normally pull code from, and every merge into this branch should be suitable for release. Every actual release from this branch receives a tag noting the version number of the release.

Receives Changes From

• Release branches
  

• Hotfix branches
  

Sends Changes To

• New hotfix branch
  

open-avb-next Branch

The open-avb-next branch is the integration point for new development. The code in this branch should be buildable, but may not be completely tested or have all features complete. This branch directly receives bugfixes and small feature implementations.

Receives Changes From

• Pull requests for bugfixes and small features
  

• Finished feature branches
  

• Periodic merges from bugfixes in release branches
  

• Periodic merges from bugfixes in hotfix branches
  

Sends Changes To

• Bugfixes merged as appropriate to feature branches
  

• Release branches branched from here
  

Feature Branches

Feature branches are created when a new feature begins development. All commits relevant to the feature go into its feature branch until it is complete, at which point it is merged back into open-avb-next and ceases to be active. Pull requests for significant changes should come from feature branches rather than one of the permanent branches.

Receives Changes From

• Branched initially from `open-avb-next`
  

• Periodically pulls changes from `open-avb-next` while development progresses.
  

• Does a final pull from `open-avb-next` before it is merged back into it upon completion.
  

Sends Changes To

• Merges upon completion with `open-avb-next` and is deleted.
  

Release Branches

Release branches are created from open-avb-next when it becomes feature-complete. The release branch thereafter receives only changes relevant to its release, while open-avb-next may continue to receive changes that will apply to subsequent releases.

Receives Changes From

• Branched initially from `open-avb-next`
  

• Relevant bugfixes that land in `open-avb-next` from hotfix branches or elsewhere
  

Sends Changes To

• Bugfixes are merged back into `open-avb-next` as they are implemented.
  

• When the release is finalized, it is merged into `master` and deleted.
  

Hotfix Branches

When bugs are reported against master, their fixes must be validated for release before being pushed to master. Hotfix branches are created to manage this process.

Receives Changes From

• Initially branched from `master` as bug fixing begins
  

Sends Changes To

• Bugfixes are merged to `open-avb-next` as they are implemented
  

• When the `hotfix` branch has been stabilized and validated, it is merged back to `master` and deleted.
  

Further Workflow Guidance

See the draft, email comments to [email protected] or submit a pull request on github against the HTML document.