Difference between revisions of "Branch Model"

Revision as of 16:55, 28 March 2013

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

Integrated projects use a YEAR.SEQUENCE numbering scheme for the common releases. Libraries use a more flexible MAJOR.MINOR.PATCH classic versioning.

Starting with Grizzly's grizzly-3 development milestone, we no longer produce per-commit versioned tarballs. Instead we produce a number of tarballs:

Branch tarballs

Every commit to the master or milestone-proposed branches results in the PROJECT-BRANCH.tar.gz tarball on http://tarballs.openstack.org/PROJECT to be renewed. This is done by the PROJECT-branch-tarball jobs on Jenkins, triggered by the friendly Zuul.

Tagged tarballs

Every time a tag is pushed to a repository, a corresponding PROJECT-TAG.tar.gz tarball is generated and uploaded to http://tarballs.openstack.org/PROJECT. This is done by the PROJECT-tarball jobs on Jenkins, triggered by the friendly Zuul. Additionally, tagged tarballs for OpenStack libraries are automatically uploaded to PyPI.

On-demand tarballs

If a user runs python setup.py sdist from a checkout of a PROJECT repository, it will generate a local PROJECT-VERSION.aXX.YYYYYY tarball.

@@ Line 1: / Line 1: @@
+== 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''):
@@ Line 5: / Line 7: @@
 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 =
+== Version numbers ==
+Integrated projects use a YEAR.SEQUENCE numbering scheme for the common releases. Libraries use a more flexible MAJOR.MINOR.PATCH classic versioning.
-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]]
+Starting with Grizzly's grizzly-3 development milestone, we no longer produce per-commit versioned tarballs. Instead we produce a number of tarballs:
-For projects with milestones and releases (Nova, Glance):
+==== Branch tarballs ====
-* The ''master'' branch generates '''VERSION~DEVMILESTONE~DATE.TRUNKREV''' (nova-2011.3~d2~20110531.302.tar.gz)
+Every commit to the master or milestone-proposed branches results in the PROJECT-BRANCH.tar.gz tarball on http://tarballs.openstack.org/PROJECT to be renewed. This is done by the PROJECT-branch-tarball jobs on Jenkins, triggered by the friendly Zuul.
-* 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):
+==== Tagged tarballs ====
-* The ''master'' branch generates '''VERSION~DATE.TRUNKREV''' (swift-1.4.1~20110531.302.tar.gz)
+Every time a tag is pushed to a repository, a corresponding PROJECT-TAG.tar.gz tarball is generated and uploaded to http://tarballs.openstack.org/PROJECT. This is done by the PROJECT-tarball jobs on Jenkins, triggered by the friendly Zuul. Additionally, tagged tarballs for OpenStack libraries are automatically uploaded to PyPI.
-* 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:
+==== On-demand tarballs ====
-* 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...)
+If a user runs <code>python setup.py sdist</code> from a checkout of a PROJECT repository, it will generate a local PROJECT-VERSION.aXX.YYYYYY tarball.