Open Stack

Hi everyone,

As more projects get into the Big Tent there have been questions
recently about release models and the development cycle. In particular,
some projects want to be independent of the common release cycle and
dates, but still keep some adherence to the development cycle.

One example of such project would be some Neutron "stadium" plug-in
which could not manage to release at the same time as Neutron, but would
still like to have a stable branch to match the Liberty neutron release.
Another example is Gnocchi, which wants to be completely independent of
the common development cycle but still maintain stable branches for
backports on specific releases. A final example is Fuel, which
traditionally made their releases a few months behind the OpenStack
release, to integrate all the functionality there.

The question ends up being, which release model should those projects
adopt ? The release team currently supports 3 models:

* release:cycle-with-milestones is the traditional Nova model with one
release at the end of a 6-month dev cycle and a stable branch derived
from that

* release:cycle-with-intermediary is the traditional Swift model, with
releases as-needed during the 6-month development cycle, and a stable
branch created from the last release in the cycle

* release:independent, for projects that don't follow the release cycle
at all

So... Should the projects in the examples above be
release:cycle-with-intermediary, or release:independent ? Can they
create a stable/mitaka branch ?

The answer lies in the definition of the common development cycle. The
common development cycle (liberty, mitaka...) is a 6-month development
cycle with a clear end date, that serves as a common reference point for
OpenStack projects that want to coordinate their development and releases.

With that definition is mind, everything that can make a release before
the end-of-cycle ("final release") date *can* follow the cycle and adopt
one of the release:cycle-with-* models. A stable/mitaka branch will be
created from that final cycle release and backports can be made there.

Projects that are not able (or willing) to make that date are
release:independent. They can make a release supporting the mitaka
release (including stable updates), but those are not part of the mitaka
release itself (since that ship has sailed already). They should clearly
document that their release is *compatible with* the OpenStack mitaka
release (rather than *part of* the mitaka release).

However, if they maintain a single stable branch for releases
*compatible* with the mitaka release, they can still call that branch
stable/mitaka (even if it is created after the mitaka release cycle
ends). For example, they can make a "3.0.0" release and then create
their stable/mitaka branch from it, so long as the stable branch is
actually stable and not a development branch. Projects maintaining more
than one stable branch per release cycle will need to use a name not
associated with the release cycle, such as the major and minor version
of the release (they can make a "3.0.0" release and have a "stable/3.0"
branch).

Looking back at our examples, all those projects should currently be
release:independent, until they are able to (and willing) to coordinate
their own releases with the projects following the common cycle. I
expect the Neutron stadium plug-ins to try to release at the same time
as Neutron (and Fuel at the same time as the OpenStack common release),
but until they can, they should be release:independent. They can still
create stable/mitaka branches if they want to. I expect Gnocchi to stay
release:independent because it has no need to track the common cycle,
and maintain its own set of stable branches.

Hoping this clarifies,

-- 
Thierry Carrez (ttx)