Release Policy
The OpenNebula project publishes this Release Cycle Policy in an effort to provide as much transparency as possible and may make exceptions as necessary.
OpenNebula follows a rapid release cycle to improve user satisfaction by rapidly delivering features and innovations based on user requirements and feedback. In other words, giving customers what they want more quickly, in smaller increments, while additionally increasing technical quality.
- Each major release or upgrade of ONE is denoted by a single major number, i.e.: ONE 5. A new major release typically means significant changes that may involve changes in the interfaces, core and data base and so may require a complex upgrade process for production environments.
- Each minor release or update of ONE is denoted by a major and a minor number, i.e.: ONE 5.8. A new minor release typically signifies enhancements, optimizations and bug fixes that may involve small changes in the core and data base and so allow a seamless update process for production environments following a pre-defined migration path.
- Each incremental release of ONE is denoted by a major, a minor and an incremental number, i.e.: ONE 5.8.1. A new incremental release typically includes only bug fixes and minor enhancements.
Incremental releases can be maintenance public or hotfix private releases.
- Hotfix private – Incremental update to fix specific issues. Although all code in OpenNebula is fully open, packages from hotfix incremental versions are not publicly released, and are only available for users with an active commercial subscription.
- Maintenance public – Incremental update between minor/major releases to fix multiple outstanding issues. Both code and packages are publicly available.
The OpenNebula project plans to release approximately:
- A new major release (upgrade) of OpenNebula approximately every 3-5 years.
- 6-10 minor releases (update) for each major version. There is an OpenNebula major or minor release approximately every 6 months.
- 1 maintenance release (incremental) for each minor version. There is at least one maintenance release between two consecutive minor releases.
- Several hotfix releases (incremental) for critical impact issues with a frequency of weeks for each minor version.
After the release of a new update (minor release) and during three months, the Project asynchronously releases hotfixes with critical bug fixes for the previous update version to allow time to update to the latest version. This period is extended to six months when the new version is an upgrade (major version).
Four weeks before an official major or minor release date, there is a beta release series. This beta series marks the feature-freeze for the release, development efforts are then mainly devoted to bug fixing and polishing.
The software is thoroughly tested through a internal quality assurance process before its release. The OpenNebula project prepares packages of all releases for the most common linux distributions. During the entire life cycle, the Project makes reasonable efforts to maintain compatibility for the core and data base across all minor and maintenance releases. The Project may elect to make exceptions to the compatibility goal for critical impact or other significant issues.
The open-source Project project can only provide community support and maintenance for the latest OpenNebula version. OpenNebula Systems offers commercial support subscriptions for users that need support for previous versions and have access to the enterprise repository with hotfixes.