Release Planning

The Apache CloudStack community uses a time-based approach to it's feature releases, with as-needed (i.e.: less formal schedule) for incremental bug-fix releases in between these feature releases. Our goal is to have a consistent schedule for new features to be merged into the master branch, along with incremental bug-fix updates between each major feature release.

Feature Release Cycle

Feature releases are planned for every 4 months, with a 2 month overlapping development window, as shown below:

Months one though four are designated for features to merge into the project's master branch.  Typically, architectural change and high risk feature additions should be introduced within the first two months of that phase.  Month five is dedicated to end to end testing of the merged features and changes, as well as documentation finalization.  Month six is focused on wrapping up final translation updates, last minute blocker bug fixes and preparing / executing the formal release voting process.

Bug-Fix Release Schedule

Bug fix (including security related bugs) are provided as incremental updates between scheduled feature releases.  The project has not decided to do them on a specific schedule, but instead when there are enough appropriately important bug-fixes applied to the source release branch, a community member will proceed with creating a release.  A single security vulnerability fix is typically considered enough to warrant a bug-fix release.

Release Branch Lifecycle

Similar to the schedule noted above, the project uses a branching strategy that reflects the overlapping nature of our work.  The master branch is considered to be the development target for new features, while release branches are created for each feature release to support stabilization of that release.  The project also considers feature release branches (which have had their feature release completed) to be a stable target from which bug-fix releases can be cut.

Versioning Numbering

Starting with our 4.0.0-incubating release, Apache CloudStack makes use of Semantic Versioning for it's release numbering. One exception to this numbering scheme, is that the "-incubating" qualifier will be added to all release numbers until the project graduates from the Apache Incubator (this is specifically due to the rules stated in the Guide to Release Management During Incubation). For those that may not be familiar with Semantic Versioning, the number format is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch number. The community strives to ensure backward API compatibility within each major version (i.e.: code written against the CloudStack 4.0.0-incubating API should work with all future 4.y.z versions). The community may decide to increment the major version number in situations where underlying implementation details require a cloud operator to face significant challenges in upgrading from one version to the next.  This should be rare situation.

In practice, feature releases will normally be an increment of the minor version number of the project.  Feature releases that break backward compatibility will cause the major version number being incremented.  Bug fix releases will never increment anything except the patch number.

Support Lifetime

asdf

Other Resources