Release Cycle

Release Schedule

The following table shows the release date of past and future versions of OpenNebula.

Version Date Release Notes
Technology Preview 1 March 26, 2008Release Notes
Technology Preview 2 June 17, 2008Incremental Release Notes
Release 1.0 July 24, 2008Release Notes
Release 1.2 (Beta1) November 30, 2008
Release 1.2 (Beta2) January 12, 2009
Release 1.2 February 6, 2009Release Notes
Release 1.4 (Beta1) July 23, 2009
Release 1.2.1 July 29, 2009Incremental Release Notes
Release 1.4 (Beta2) October 30, 2009Release Notes
Release 1.4 RC November 18, 2009Release Notes
Release 1.4 December 16, 2009Release Notes
Release 2.0 (Beta1) July 17, 2010Release Notes
Release 2.0 RC1 September 23, 2010Release Notes
Release 2.0 October 25, 2010Release Notes
Release 2.0.1 December 3, 2010Incremental Release Notes
Release 2.2 (Beta) March 2, 2011 Release Notes
Release 2.2 RC1 March 20, 2011 Incremental Release Notes
Release 2.2 March 29, 2011 Release Notes
Release 2.2.1 Jun 9th, 2011 Incremental Release Notes
Release 3.0 (Beta) July 20, 2011 Release Notes
Release 3.0 (Beta2) September 8, 2011 Incremental Release Notes
Release 3.0 RC1 September 23, 2011 Incremental Release Notes
Release 3.0 October 3, 2011 Release Notes
Release 3.2 - S0 + S1 November 18, 2011 Release Notes
Release 3.2 Beta December 16, 2011 Incremental Release Notes
Release 3.2 RC December 23, 2011 Release Notes
Release 3.2 January 17, 2012 Release Notes
Release 3.2.1 January 30, 2012 Incremental Release Notes
Release 3.4 - S0 February 21, 2012 Release Notes
Release 3.4 Beta March 30, 2012 Release Notes
Release 3.4 April 11, 2012 Release Notes
Release 3.4.1 May 3, 2012 Incremental Release Notes

Release Cycle 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 upgrade or major release of ONE is denoted by a single major number, i.e.: ONE 2. 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 update or minor release of ONE is denoted by a major and a minor number, i.e.: ONE Pro 2.2. 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.

The OpenNebula project plans to release a new upgrade of OpenNebula approximately every year and to provide three updates for each major version. This means that there is an OpenNebula release every three months. Prior to the official release date there is a beta (two weeks before) and a candidate release (a week before). These two releases are feature-freeze and are mainly devoted to bug fixing and polishing. The features for each release are prioritized and developed in three one-month sprints. At the end of each sprint there is available an OpenNebula pre-release that incorporates the features and bugs solved in that sprint.

The software is thoroughly tested through a internal quality assurance process before its release. The OpenNebula pre-releases go through the same testing and certification process as the official releases, i.e. you should expect the same levels of stability. The OpenNebula project prepares packages of all releases and pre-releases for the most common linux distributions.

The OpenNebula project can only provide support and maintenance for the last minor (update) version. OpenNebula moves quickly because is focused on open source innovations. If you want a distribution with a longer lifecycle and time support, OpenNebulaPro, which is the commercially supported derivative of OpenNebula, might be more suitable for you. C12G Labs provides support and maintenance during 5 year periods for each of the major releases of OpenNebula through its OpenNebulaPro distribution.

Project Roadmap

How Do We Define our Roadmap?

Our vision, mission, objectives and design principles serve as the framework for the definition of our long term roadmap and guide every aspect of our project by describing what we need to accomplish in order to continue to fulfill our promise of building a state-of-the-art open source toolkit that addresses the scalability, flexibility and security requirements of large-scale production systems.

The requirements of our users are the driving force behind all our development efforts. OpenNebula features fulfill real needs of leading IT organizations running production environments. Cloud Computing is a highly competitive market that presents challenges for the continued success of OpenNebula, we must ensure that we can deliver a product that is compelling to users in order to continue to be able to demonstrate our vision for the cloud. This requires us to be agile and flexible in order to quickly adapt to our user needs and the market challenges. So the roadmap needs to be flexible enough to deal with and take advantage of rapid changes in cloud and data center developments. This is the reason why we only publish our short-term roadmap, which is the description of the features planned for the next release of the software.

How Do We Prioritize Features in our Short-term Roadmap?

When we create the short-term roadmap and plan the features for the next release, we prioritize:

What is the Roadmap for the Next Release?

A detailed list of planed features for the upcoming release of OpenNebula is available in the development page.