ONOS runs "train" based releases. That means whatever is ready to board the train, does so. Whatever isn't ready, has to wait for the next train. This enables us to have a very predictable release cadence making it easy to plan around. It also puts the responsibility on project owners to make sure they have features ready for the release. ONOS releases quarterly at the end of February, May, August, November. It is offset from the "normal" quarters because we all know that nothing happens for half of December. At the beginning of a release cycle, we have a planning meeting and two weeks before the end of the release we freeze integration of new features:
Releases last 3 months. Each release starts with a planning meeting (check the ONOS calendar). After planning, development teams build their deliverables using whatever methods (scrum, kanban, waterfall...) they want but must their code frequently (daily?), leading up to the last 2 weeks. The project does not accept "dumps" of code at the end. Commit early and often on master. Two weeks before the release date, we halt feature integration and only allow bug fixes. At some point during those two weeks, we start the release candidate process. This process starts by pulling a branch off master that will become the release branch. That frees up master for development on the next release. On the release candidate branch we work on bug fixes, and choose "release candidate", RC, tags. The software at that tag is a candidate for release, and it is submitted to a more rigorous set of testing. If it passes, we can officially tag it as the release. If it doesn't, we enter another bug fix cycle and create a new release candidate. We iterate until we have a candidate that can be the formal release. Usually, this takes 2-3 cycles and 1-3 weeks of time. More details on branching can be found in the contributor guide portion of the wiki.
Release Branching, Versioning and Tags
- Master branch (master): Main development will happen on the master branch. This is the latest and greatest branch, but is always "stable" and "deployable". All tests always pass on this branch.
- Maintenance branch (support): This is the long-term maintenance branch per release.
- Development branch (dev): This is a branch created for lengthy and/or involved feature development that could destabilize master. The development branches need to be proposed to and signed off by the Technical Steering Team.
Each ONOS release will have the following version format:
- Either the <major> or the <minor> version will be incremented for each release. The Technical Steering Team will decide whether to increment the major or minor number for the release. This decision will depend on a number of different factors such as incompatibility with existing APIs etc.
- <revision> is incremented for a fix (or set of fixes) on a maintenance branch that justifies a new maintenance "release". Note: the revision number is optional when it is zero.
- 1.0.0rc1 - release candidate for 1.0.0. rc1 is a temporary tag that gets cleaned up after 1.0.0 is tagged final.
- 1.0.0 - Open source ONOS release on Dec 5th, 2014
- 1.0.1 - First maintenance release for 1.0.0
The past two releases will be supported. The only changes allowed on these releases will be security patches and critical defects that are blocking deployments. Security patches will be proactively applied to the supported releases, whereas critical defects will be addressed by community request. The defects should have JIRA tickets associated with them. Releases will be done periodically, as needed. A release can be requested by the community by sending a request to the TST mailing list.
Defects fixes in previous versions should be ported forward to all versions released since then, including master. For example, a fix in version 1.8 should be ported to 1.9, etc... and master. The module owner should assess the changes and drive the cherry-pick process.
During the development cycle and for easy identification post-release, each release is also identified by a "code" name in addition to the version. Releases are named after birds because they are beautiful, found worldwide, are colorful and graceful, make beautiful music...and because they signify something taking flight into the wild blue yonder, something we advocate for SDN and NFV. Finally, and perhaps most importantly, birds work together in flight to reduce the load on each other so that they can fly long distances (for example, the V formation)...and, we hope that everyone in the ONOS community will adopt the same philosophy of helping each other to make ONOS great. We name them in alphabetical order.
Release Names and Versions
|Name||VERSION||Dates||Notes||About the name||Presentation||Related Press|
May 31, 2017
FF: May 12, 2017
Feb. 28, 2017
FF: Feb. 10, 2017
|Release Content||About the bird|
|Ibis||1.8.0||Dec. 2, 2016||Release Content||About the bird|
|Hummingbird||1.7.0||Aug. 31, 2016||Feature Summary||About the bird||pptx||Press|
|Goldeneye||1.6.0||Jun. 10, 2016||Release Notes||About the bird||pptx||Press|
|Falcon||1.5.0||Mar. 10, 2016||Release Notes||About the bird||pptx||Press|
|Emu||1.4.0||Dec. 16, 2015||About the bird||pptx||Press|
|Drake||1.3.0||Sept. 18, 2015||About the bird||pptx||Press|
|Cardinal||1.2.2||Sept. 1, 2015|
(Stanford "Cardinal" refers to the color, NOT the bird)
|1.2.1||June 25, 2015|
|1.2.0||June 5, 2015|
|Blackbird||1.1.0||Mar. 17, 2015||Press|
|1.0.1||Jan 21st, 2015||About the bird|
|1.0.0||Dec 5th, 2014|
To generate release detailed notes, use https://jira.onosproject.org/secure/ReleaseNote.jspa?projectId=10105
You can find details on versioning and naming of releases here.