Jump to: navigation, search

Branch Model

Revision as of 16:57, 28 March 2013 by ThierryCarrez (talk | contribs) (Version numbers)


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. Interim development milestones are versioned YEAR.SEQUENCE.MILESTONE. Libraries use a more classic and 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.