Difference between revisions of "Branch Model"
(Restore image) |
|||
Line 3: | Line 3: | ||
Starting with the Diablo cycle, OpenStack core projects use a branching model close to the [http://nvie.com/posts/a-successful-git-branching-model/ NVIE model] that ensures an almost-always-open ''master'' while still allowing to freeze features and select bugfixes in a release branch (''milestone-proposed''): | Starting with the Diablo cycle, OpenStack core projects use a branching model close to the [http://nvie.com/posts/a-successful-git-branching-model/ NVIE model] that ensures an almost-always-open ''master'' while still allowing to freeze features and select bugfixes in a release branch (''milestone-proposed''): | ||
− | + | [[File:modelbd.png]] | |
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. | 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. |
Revision as of 16:42, 28 March 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 produce artifacts that are leading up to a release and drive a lot of automation, we produce automatic version numbers. Prior to Grizzly, we used a different versioning scheme, which remains documented at OldVersionNumbers
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)
With:
- 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...)