Difference between revisions of "Branch Model"

Revision as of 13:03, 16 June 2016

OpenStack projects which follow the release cycle 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 release branches (one per cycle). Some follow a model with development milestones and a final release at the end of the cycle, while some follow an alternative model which allows for multiple intermediary releases in every cycle.

Model with milestones

Here is how it works. Suppose that we are currently in the foo development cycle, which will lead to the final x.0.0 release. When we hit the foo-1 development milestone, we push a x.0.0.0b1 tag on the master branch. Same for the foo-2 development milestone. When we hit foo-3, we push a x.0.0.0b3 tag, and we start a feature-frozen period, during which the focus switches to fixing release-critical bugs. When all those bugs are fixed, we push a x.0.0.0rc1 tag and publish the first "foo" release candidate for that project. At this point we create a stable/foo pre-release branch. The master branch is no longer feature-frozen: it is now open for the next cycle (foo+1) development. If further release-critical bugs are found in the release candidate, we backport the release-critical bugfixes to stable/foo, and when we fix all new release-critical bugs, we tag a new RC. On release day, we tag the current RC as the final release (x.0.0). From that point on stable/foo is managed by the Stable Team and gets critical bugfixes backported and will regularly tag and publish point releases (the first one being x.0.1) until it reaches end-of-life.

@@ Line 1: / Line 1: @@
-== Model ==
+OpenStack projects which follow the release cycle 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 release branches (one per cycle). Some follow a model with development milestones and a final release at the end of the cycle, while some follow an alternative model which allows for multiple intermediary releases in every cycle.
-OpenStack integrated 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 proposed/* branches (like ''proposed/juno''). Starting with the Juno cycle, we no longer use release branches for intermediary milestones.
+=== Model with milestones ===
-Here is how it works. Suppose that we are currently in the ''foo'' development cycle, which will lead to the final ''y.s'' release. When we hit the '''foo-1''' development milestone, we push a '''y.s.0b1''' tag on the master branch. Same for the foo-2 development milestone. When we hit '''foo-3''', we push a '''y.s.0b3''' tag, and we start the [[FeatureFreeze]] period, during which the focus switches to fixing release-critical bugs. When all those bugs are fixed, we push a '''y.s.0rc1''' tag and publish our first foo release candidate. We create a '''stable/foo''' pre-release branch. [[FeatureFreeze]] ends on the master branch, which is now open for the next cycle (foo+1) development. If further release-critical bugs are found in the release candidate, we backport the release-critical bugfixes to stable/foo, and when we fix all new release-critical bugs, we tag a new RC. On release day, we tag all current RCs as the final release ('''y.s.0'''). From that point on '''stable/foo''' is managed by the Stable Team and gets critical bugfixes backported and will regularly tag and publish point releases (the first one being '''y.t.1''') until it reaches end-of-life.
+Here is how it works. Suppose that we are currently in the ''foo'' development cycle, which will lead to the final ''x.0.0'' release. When we hit the '''foo-1''' development milestone, we push a '''x.0.0.0b1''' tag on the master branch. Same for the foo-2 development milestone. When we hit '''foo-3''', we push a '''x.0.0.0b3''' tag, and we start a feature-frozen period, during which the focus switches to fixing release-critical bugs. When all those bugs are fixed, we push a '''x.0.0.0rc1''' tag and publish the first "foo" release candidate for that project. At this point we create a '''stable/foo''' pre-release branch. The master branch is no longer feature-frozen: it is now open for the next cycle (foo+1) development. If further release-critical bugs are found in the release candidate, we backport the release-critical bugfixes to stable/foo, and when we fix all new release-critical bugs, we tag a new RC. On release day, we tag the current RC as the final release ('''x.0.0'''). From that point on '''stable/foo''' is managed by the Stable Team and gets critical bugfixes backported and will regularly tag and publish point releases (the first one being '''x.0.1''') until it reaches end-of-life.
 [[File:branchmodel.png]]
-== Version numbers ==
-Integrated projects use a YEAR.SEQUENCE numbering scheme for the common releases. While it is under development, it uses "beta" pre-versioning to number development milestones: YEAR.SEQUENCE.0bN, with N being the development milestone number.
-Note that OpenStack libraries use a more classic and flexible MAJOR.MINOR.PATCH semver 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 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, still triggered by the friendly Zuul. Additionally, tagged tarballs for OpenStack libraries are automatically uploaded to PyPI.
-==== On-demand tarballs ====
-If a user runs <code>python setup.py sdist</code> from a checkout of a PROJECT repository, that will generate a local PROJECT-VERSION.aXX.YYYYYY tarball.