The project plans to produce the following types of releases:

• Regular: Introduce new features and enhancements.  These releases are targeted for users who require the newest features as early as possible and are able to upgrade when the releases are available.
• Long Term Support (LTS):  Focuses on the stability and longevity of releases at the expense of new features.  These releases are targeted for users who require stability over the availability of new features and/or have longer upgrade windows.
• Security: Small releases that include only CVE fixes.  These releases are produced for all impacted and supported Regular and LTS releases at the time of CVE identification.  Because these releases contain only CVE fixes, all users should upgrade to the latest security release of their preferred type (regular or LTS)  as soon as possible.

This LTS release cycle has the following goals:

• Stability over new features: Deliver releases that only address defects and CVEs. No features or enhancements** would be backported to LTS release branches. This greatly reduces the upgrade risk / operational impact.
• Reliable Release Lifetimes: The LTS release cycle will provide users with reliable support and upgrade time frames.
  ** LTS may accept enhancement if it adds support for an important component upgrade such as support for a new hypervisor version to allow users to upgrade their infra without requiring them to perform a full CloudStack major upgrade.

Release versioning conforms to the semantic versioning 2.0.0 standard where by the major release is increment when a backwards-incompatible change is introduced.  The following are examples of backwards-incompatible changes that would trigger an increment of the major release position:

• Public API incompatibility
• Mandatory Java major release upgrade
• Mandatory MySQL release upgrade
• Removal of a supported component

Therefore, CloudStack users can expect that a family of major CloudStack releases is based on the same major Java/MySQL versions, maintain API compatibility, and supports for infrastructure components only expands.  The project's release numbering differs slightly from Semantic Versioning as follows:

• <MAJOR>.<MINOR>.<NON-SECURITY PATCH>.<SECURITY PATCH> where NON-SECURITY PATCH is incremented for all bug fix releases except those addressing a CVE.  The SECURITY PATCH is only incremented for security releases that fix one or more CVEs.

Finally, branch management and PR approval for regular and LTS releases processes follow those outlined in the CloudStack Release Principles topic.  Due to their confidential nature of CVE mitigation, patches must be reviewed privately and cannot be submitted as PRs.  Therefore, the security team reviews these patches privately – tracking the two (2) required LGTMs on the security@ mailing list.  

Release Cycles

The section outlines the process through which each release type of produced by the community.  

Long-Term Service (LTS) Release Cycle

.LTS branches are supported for a total of 18 months in the following manner:

• 1-12 months: All Blocker and  Critical defect fixes, as well as, CVEs identified in the LTS branch will be merged and released.
• 12-18 months: All Blocker defect and CVEs that impact the LTS branch will be merged and released.  LTS maintenance releases will occur as needed during this period.

The following are the types of changes that are permitted and guarantees provided to users:

• Defect fixes only.  Enhancements for that expand support for existing plugins (e.g. XenServer 7) and additional JDK/JRE or MySQL versions may be considered if the change is sufficiently isolated and do not introduce significant-quality release to the branch.
• Database changes will be limited to those required to address defect fixes
• Supported JDK/JRE, MySQL, and Linux distribution versions will not be removed throughout the cycle

Defect fixes that originate in an LTS branch will be forward merged to the supported regular release and master branches.

Security Release Cycle

When a CVE is identified, the security team requires a private, expedited release process to address the issue.  Users also need a release that is constrained to fixing only the CVE to minimize upgrade risk and downtime.  Therefore, when a security release is required, the security team will review the proposed patch privately with a minimum of two (2) LGTMs required per our release principles.  The patch will be forward merged to every impacted regular and LTS release currently supported – incrementing the security patch number.  The security team will then create a release candidate for each security release and vote on each release candidate according to the community's bylaws. Security issues should be reported to security@apache.org  

LTS Release Calendar

Notes:

• These dates assume that no blocker or critical defects are identified that require an earlier release
• Release dates are based on the git tag or source tarball date
• LTS releases starting with the first major release will be supported for a minimum of 6 months after next LTS release or a total period of 18 months, whichever is greater