Releases

1. Release Cycle
2. Release Naming
3. Submitting new feature or project proposal
4. Branching model

You can view details of all ONOS Releases at:

1. Release Schedule
2. Release Notes
3. Release Content
4. Roadmap 2015 (Initial proposal- to be finalized with input from service providers, vendors, community i.e. you)
   1. Distributed Core
   2. Application Intent Framework
   3. Southbound

RELEASE CYCLE

Release Frequency

ONOS releases have a 3 month time-based release cycle.

A new ONOS release will be available on the last day of the following four months:

• February
• May
• August
• November

Development items and bugs for each release are tracked through JIRA. If you are new to JIRA, you can learn more about using JIRA for ONOS on the ONOS JIRA wiki page.

Release Stages

Planning

 At the beginning of each ONOS release cycle, proposed content for the release is discussed and prioritized. The proposed content i.e. the backlog (in Agile terminology) is tracked in JIRA.

Development

Developers submit code to Gerrit for review, and this code gets merged upon acceptance.  Learn more about the development process here.

Pre-release (Tagging release candidates)

Once all the development milestones are met and release-critical bugs are fixed, the first candidate for that release (RC1) is tagged. This RC1 build will be used as the final release, unless new release-critical issues are found in which case these are fixed and a new RC tag is applied to the subsequent build.

Code Freeze

Code freeze happens 15 days before the release date. This is subject to change.

Release

On release day (as described above in Release Frequency), the last tagged release candidate is re-versioned and published as the release on onosproject.org. You can find details on release versioning here.

Return to Releases section.

RELEASE NAMING

Release Versioning and Tags

Each ONOS release will have the following version format:

Format: <major>.<minor>.<revision>

• 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.
  
  

Example:

Here is how this versioning will work for the Dec 5th, 2014 open source release:

• 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 first open source release on December 5th, 2014 will have the 1.0.0 version number. The next release in February, 2015 could be versioned either 1.1.0 or 2.0.0 based on the decision of the Technical Steering Team.

Release Naming

During the development cycle and for easy identification post-release, each release is also identified by a "code" name in addition to the version. In keeping with the ONOS bird logo and the theme of openness and freedom, ONOS releases will be named after "Birds" in alphabetical order. Name of the first open source ONOS release is "Avocet" and is "EMu" for the next release in December, 2015.

For all releases after the February release, at the beginning of each release cycle, 3 names will be pre-selected by the Releases Steering team and provided to the ONOS Community via an online poll. The winning name will be used for the release. Only single word bird names with 10 characters or less are preferred for the release name but outside of these constraints, the Releases Steering Team and the Community have free rein.

The second release in 2016 will have the name of a bird starting with "g". Please email your suggestions for the August release name to onos-release-team@onosproject.org.

List of Release Names

 

Release Name	Release Number	About the name	Release Date
Avocet	1.0.0	About the bird	Dec 5th, 2014
Blackbird	1.1.0	About the bird The legendary Blackbird Jet In honor of Beatles	Feb 28th, 2015
Cardinal	1.2.0	About the bird (Stanford "Cardinal" refers to the color, NOT the bird)	May 31st, 2015
Drake	1.3.0	About the bird	September 18th, 2015
Emu	1.4.0	About the bird	December 18th, 2015
Falcon	1.5.0	About the bird	March 10th, 2016

 

Return to Releases section.

SUBMITTING A NEW FEATURE PROPOSAL 

Types of proposals:

• The proposal is related to Core ONOS modules
• The proposal is for an external module or application or product unrelated to ONOS core.

You can find details on submitting a new feature proposal here.

Return to Releases section.

BRANCHING MODEL

Branches

ONOS branching model:

• 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.

You can find details on versioning and naming of releases here.

Return to Releases section.

RELEASE SCHEDULE

 

Release	Version	Release Date	Status
Avocet	1.0.0	December 5th, 2014	Released
Blackbird	1.1.0	February 28th, 2015	Released
Cardinal	1.2.0	May 31st, 2015	Released
Drake	1.3.0	September 18th, 2015	Released
Emu	1.4.0	December 18th, 2015	Released
Falcon	1.5.0	March 10th, 2016	Released

Status

The status field can have one of the following values:

• Under Development
• Proposed
• Released

Return to Releases section.