Jump to: navigation, search

Difference between revisions of "Branch Model"

Line 1: Line 1:
= [[OpenStack]] branch model =
= [[OpenStack]] branch model =

Revision as of 20:51, 16 February 2013

OpenStack branch model

Starting with the Diablo cycle, OpenStack core projects use a branching model close to the NVIE model that ensures an almost-always-open master while still allowing to freeze features and select bugfixes in a release branch (milestone-proposed):


At some point before the release of a milestone (called the "branch point"), the milestone-proposed branch gets created out of the master branch. The master branch continues towards the development of the next milestone. The milestone-proposed branches gets testing and backported bugfixes (that must land in master first), until the release is tagged.

Version numbers

Since we have two branches in parallel, we use version numbers that allow to upgrade from one to the other.

For projects with milestones and releases (Nova, Glance):

  • The master branch generates VERSION~DEVMILESTONE~DATE.TRUNKREV (nova-2011.3~d2~20110531.302.tar.gz)
  • The milestone-proposed branch generates VERSION~MILESTONE~DATE.rMPREV (nova-2011.3~d1~20110531.r301.tar.gz)
  • This gets copied at milestone delivery time to VERSION~MILESTONE (nova-2011.3~d1.tar.gz)
  • This gets copied at coordinated release time as VERSION (nova-2011.3.tar.gz)

For projects where milestones == releases (Swift):

  • The master branch generates VERSION~DATE.TRUNKREV (swift-1.4.1~20110531.302.tar.gz)
  • The milestone-proposed branch generates VERSION~DATE.rMPREV (swift-1.4.0~20110531.r301.tar.gz)
  • This gets copied at release time as VERSION (swift-1.4.0.tar.gz)


  • VERSION being the version of the project under development (2011.3, 1.4.0)
  • DEVMILESTONE being the short name of milestone under development (d2) and MILESTONE being the milestone about to be released (d1)
  • DATE being under YYYYMMDD form
  • TRUNKREV is a sequential revision on master
  • MPREV is a sequential revision on milestone-proposed

Those (seemingly complex) version numbers actually ensure that you can smoothly upgrade in all scenarios (from trunk to milestone-proposed and back to trunk and to the final version...)