Jump to: navigation, search

Simultaneous Release:Helium Release Plan


This is a Simultaneous Release Plan for OpenDaylight. Projects may choose to participate or not based upon their readiness and desire to join the Simultaneous Release. This plan is structured as laid out in the Project Lifecycle

Requirements for Participation

  1. Planning
    1. Projects must declare their intent to participate in the Simultaneous Release by M1.
    2. Participating projects must publish a candidate Release Plan by M1 and declare their Release Plan by M2
      1. Participating project Release Plans must contain Milestones that minimally line up with the Simultaneous Release Plan Milestones
  2. Modularity
    1. Modules that are not intended to interface with the controller via REST/other rpc mechanism must be OSGI bundles
    2. OSGI bundles should be reasonably granular
  3. Quality
    1. No later than M3, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts (Continuous Integration Test Start)
    2. No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repo.
  4. Code Hygiene
    1. No uses of System.out.println in non testcase code.
    2. No dependencies on 3rd party (non-ODL) snapshot versions

Packaging, Tests and Documentation Expectations

As part of the simultaneous release there are some expectations on what projects should provide to facilitate packaging, tests and documentation.

Please see Project Expectations for information about what is expected from projects to facilitate the simultaneous release. r

Aspirations and Intentions

There are certain things we would like to achieve procedurally for the Helium Release that we are not in a position to require because they are not yet worked out. In order to provide a stable set of expectations they will not be required, but will be *strongly* encouraged as the details of how to achieve them are worked out.

  1. Continuous Release - The automated cutting of a regular set of release artifacts from each project (expected to be weekly).
  2. Continuous Documentation - The ongoing updating of documentation and its automatic assembly in the hopes of always being in a state of being documented

Note: The mechanics of how to achieve these aspirations are being worked out, and are expected to be figured out early in the Helium cycle, but are not yet known.

Milestones, Release Candidates, and Service Releases

Milestones are spaced 4 weeks apart.

Release Candidates (RC) are spaced 1 week apart

Service Releases are roughly 6 weeks and 12 weeks (holiday adjusted) after the Formal Helium Release.


Milestone Date Events
M0 4/14/2014 Simultaneous Release Open
Last call for new projects eligible to join 4/30/2014

This is the latest date a project proposal can be brought and still have the two week public comment period before its project creation review at the last TSC meeting before it needs to declare its intent to join the Simultaneous Release at M1.

M1 5/12/2014
  1. Projects must have declared intent to participate in Simultaneous Release
  2. Participating Projects must have published a candidate Release Plan for public comment ( Release Plan Template )
  3. TSC commits to initiate public discussion of Lithium Simultaneous Release Plan
M2 6/09/2014
  1. Participating Projects must have declared their final Release Plan
  2. TSC commits to finalize basic dates and Milestones for the Lithium Simultaneous Release Plan (some details of requirements and Milestone contents may be decided later).
  3. TSC commits to initiate public discussion of Release Vehicles
M3 7/07/2014
  1. Latest possible Continuous Integration Test Start
  2. TSC commits to decide on Final Release Vehicles Defined
  3. Latest possible date for commencing Documentation
M4 8/04/2014
  1. API Freeze
  2. Latest possible Continuous System Test Start
  3. TSC commits to begin public discussion of Stable Update Expectations
M5 9/4/2014
  1. Code Freeze (bug fixes only from here)
  2. String Freeze (all internationalizable strings frozen to allow for translation)
  3. TSC commits to have finalized Stable Update Expectations
RC0 9/9/2014
RC1 9/15/2014
RC2 9/22/2014 Participating Projects must hold their Release Reviews, including User Facing Documentation.
Formal Helium Release 9/29/2014
  1. Formal Helium Release
  2. Latest possible date for each project to add a stable/helium branch
SR1 (Stable Release 1 aka Helium.1) 11/10/2014

First Stable Update for Helium. See Stable Update section. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.

SR2 (Stable Release 2 aka Helium.2) 01/26/2015

Second Stable Update for Helium. See Stable Update section. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.

SR3 (Stable Release 3 aka Helium.3) 03/26/2015

Third Stable Update for Helium. See Stable Update section. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.

SR4 (Stable Release 4 aka Helium.4) 07/16/2015

Fourth Stable Update for Helium. See Stable Update section. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.

Please note that the TSC reserves the right to allow projects to enter the Simultaneous Release for a reasonable period of time after the M1 date.

For example, the TSC may allow additional time if a project is delayed by the IPR Review process.

Please also note that projects that may be splitting into logical parts may have those logical parts join the Simultaneous Release at any point prior to M3 provided their Release Plans are apportioned between the projects they split into.

Participating Projects

Project Release Plan Contact Contact Email Contact IRC Nick
AAA Service Release Plan Liem Nguyen liem_m_nguyen@hp.com liemmn
BGPCEP Release Plan

Dana Kutenicsova
Robert Varga


Controller Release Plan Ed Warnicke eaw@cisco.com edwarnicke
dLux Release Plan Harman Singh (harmasin) harmasin@cisco.com harmasin
Defense4All Release Plan

Oron Asaf


Docs Release Plan Manny Set eset@cisco.com manny
Group Based Policy Release Plan Keith Burns alagalah@noironetworks.com alagalah
Integration Group Release Plan Luis Gomez ecelgp@gmail.com LuisGomez
L2 Switch Release Plan

Amit Mandke
Alex Fan


Lisp Flow Mapping Service Release Plan Vina Ermagan
David Goldberg
ODL-SDNi App Release Plan Rafat Jahan rafat.jahan@tcs.com rafat
OpenFlow Plugin Release Plan Abhijit Kumbhare abhijitkoss@gmail.com abhijitkumbhare
Openflow Protocol Library Release Plan Michal Polkorab michal.polkorab@pantheon.sk oflibMichal
OVSDB Release Plan

Madhu Venugopal
Brent Salisbury



PacketCablePCMM Release Plan Thomas Kee t.kee@cablelabs.com xsited
Secure Network Bootstrapping Infrastructure Release Plan Frank Brockners fbrockne@cisco.com brockners
Service Function Chaining Release Plan Paul Quinn paulq@cisco.com paulq
Southbound plugin to the OpenContrail platform Release Plan Priyanka Chopra pchopra@juniper.net PriyankaChopra
SNMP4SDN Release Plan Yi-Ling (Christine) Hsieh ylhsieh@itri.org.tw ChristineH
Table Type Patterns Release Plan Colin Dixon colin@colindixon.com colindixon
TCP-MD5 Release Plan Robert Varga rovarga@cisco.com rovarga
VTN Project Release Plan

Masashi Kudo
Hideyuki Tai



YANG Tools Release Plan Tony Tkacik ttkacik@cisco.com ttkacik

Participating projects should list themselves here prior to M1, with a link to their Project wiki page, Release Plan as well as primary contact information.

Helium Project Dependency Diagram


Decision on the Use of Karaf for Feature Selection Within Helium

The projects participating in the Helium simultaneous release need to decide if we are using Karaf for feature selection or not. This decision impacts all projects that are part of the release so each project must commit to supporting Karaf if we are to use it in Helium.

Information on Karaf within OpenDaylight


OpenDaylight Status Spreadsheet: direct link to sheet

Communication Channels

Mailing List

release@lists.opendaylight.org is the formal channel for communication about the Simultaneous Release.

release-dev@lists.opendaylight.org is the developer's discussion channel for communication about the Simultaneous Release.

IRC Channel

  • #opendaylight-release
  • #opendaylight-meeting

Per project Simultaneous Release Contact

Each project participating in the Simultaneous Release should designate a committer to be the contact for that project for that Simultaneous Release

Cross Project Milestone and Release Candidate Reporting

Negative status needs to be reported promptly. If a project is under threat of, or does miss an element on its Release Plan, it should report that as soon as it becomes aware.

Positive Status need to be reported by each project at each Milestone Reporting status for that Milestone or Release Candidate. Information would include things like pointers to continuous integration Jenkins Jobs, etc.

It is the responsibility of each projects Simultaneous Release Contact to report both positive and negative statuses.

Simultaneous Release Developer Meetings

One week prior to each Milestone or Release Candidate starting at M1, an IRC meeting for developer interested in the Simultaneous Release should be organized for real time coordination and checkin. The Simultaneous Release Contact for each project (or their delegate) should minimally be in attendance.

Developer Meeting Schedule

  • M3 - Wednesday 7/9/2014 8:30am PST on #opendaylight-meeting
  • M4 - Wednesday 7/30/2014 8:30am PST on #opendaylight-meeting
  • M5 - Wednesday 8/27/2014 8:30am PST on #opendaylight-meeting
  • RC0 - Wednesday 9/3/2014 8:30am PST on #opendaylight-meeting
  • RC1 - Wednesday 9/10/2014 8:30am PST on #opendaylight-meeting
  • RC2 - Wednesday 9/17/2014 8:30am PST on #opendaylight-meeting


Bugs should be filed in Bugzilla

Bug Tracking

Helium release bug statistics in Bug Tracking

Proposed Release Vehicles

Service Release Recommendations

Please see Helium Service Release Recommendations for information about branch naming, patch criteria, service release criteria.


Google docs spread sheet for tracking goes here

Useful References