Page History

...

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

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.

...

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.

...