Running from the trunk

As we mentioned before, stable releases of OpenStack happen on a 6-month cadence. Active development happens in the trunk of each of the software projects (the master branch on the web-based repository service for OpenStack at: http://git.openstack.org). This master repository controls the distributed version control for the OpenStack project and aids in source code management. This is very similar to the well-known GitHub service used by many other open source projects. In addition to the Git repository, there are some number of stable branches corresponding to the 6-month releases. Features are implemented in the master branch, and bug fixes are backported from the trunk to the branches on an irregular basis.

For most organizations, taking a packaged version of one of the stable branches and deploying it will suffice. There are a couple of reasons why this might not be appealing, though. For one, some organizations might find that too much change accumulates between the 6-month releases and that there's less risk in releasing more frequent and smaller changes from the trunk. Although this makes sense with a lot of software projects, OpenStack is developed by a number of loosely coordinated teams, and managing the dependencies between the development streams of each project is a complicated task. Automated testing on the trunk attempts to ensure that a change in Nova doesn't break a feature in Neutron, but the bulk of manual integration testing happens for the coordinated stable releases.

Although it's possible that an organization may want to take all the changes from the trunk before they make it down to the stable branches, it's more likely that they'll be interested in only one or two important features that haven't made it to the branches. For example, many of the teams that we have worked with were interested in leveraging external IPAM systems similar to the one provided by Infoblox long before the feature was implemented in Neutron (in the Liberty release). We've seen other situations in which an organization wanted to pull in a Cinder driver for a new SAN device before it was accepted upstream. For these use cases, it makes more sense to start off with a packaged distribution of one of the stable branches and then create a custom package only for the component that has the desired feature backported to it from the trunk.