View source for OldVersionNumbers

= [[OpenStack]] branch model =

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''):

{{http://img32.imageshack.us/img32/3438/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.

= 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)

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...)