Skip to content

Basho repository management

John R. Daily edited this page Aug 26, 2013 · 3 revisions

Background

Most of Basho's GitHub repositories (including Riak) historically used the master branch for active development, with releases tagged from master.

The team developing Riak CS uses a different structure based on git-flow.

In August of 2013, in preparation for the stabilization of Riak 2.0, we decided to standardize on the Riak CS branch naming convention and implement our processes around that.

Repository naming

  • All Basho repositories will have two or three primary branches:
    • develop - For active development via pull requests. This will be the default branch in GitHub
    • master - For release-quality code
    • staging - For code that has passed automated testing. This will typically only exist for larger repositories
  • Working branches should include feature/ or bugfix/ as a naming prefix
    • E.g., feature/jdb-thumbprint-recognition

Release branches

  • Each code freeze for a pre-release up to but not including the last freeze will result in a tag on staging (e.g., 2.0-pre1)
    • Bug fixes during these code freezes will follow the normal process: pull requests against develop, then merged to staging
  • The last pre-release code freeze will result in a release branch off staging, named after the release
    • E.g., we will branch staging to a new 2.0 branch
    • From this point forward, effectively all development will be bug fixes in the form of pull requests against the new branch
  • Each release candidate will be tagged on the release branch (2.0-rc1)
  • The production release will be tagged (2.0.0) and merged back to develop and master for tagging and shipment

Illustrated

Basho git repository process