Overview

All available releases can be found on the Apache CloudStack project's website, on the Downloads page. The release-specific child pages in this wiki are not intended to be the official documentation for any release, but are intended to be documents used by the Apache CloudStack community for collaboration and delivery of releases.

...

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, giving each feature 6 months to go through it's cycle.

...

Voting on a release is a formal act within the ASF. For that reason, no specific release day can be scheduled in advance (only the start of the first round of voting). For more information about that process, see the Apache Release Policy.

Typically, the project will have one or more release votes, which last at least 72 hours each.  The release manager has the right to cancel any release vote, if an issue is discovered that warrants a fix and restart of the voting process.

Bug-Fix Release Schedule

...

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.

Fixes that are typically applied to both master and any active / relevant release branch.

Versioning

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). Releases of CloudStack from before it's donation to the ASF did not follow Semantic Versioning.

...

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 to be incremented. Bug fix releases will never increment anything except the patch number.

Support Lifetime of a

...

Release

Due to the Apache CloudStack community's adoption of Semantic Versioning, the project has chosen to adopt a release support model as follows:

...

Given the nature of this release support model, the community believes that providing an upgrade path from any CloudStack release to any later CloudStack release is a critical feature for our users. This includes upgrades from one major version number to the next. It should be expected that any exception to a smooth upgrade path is either a critical bug to be addressed, or will be documented very clearly (and it will cause a major version number increment).

Other Resources

...

...