Simultaneous Release:Helium Release Plan
- 1 Introduction
- 2 Requirements for Participation
- 3 Packaging, Tests and Documentation Expectations
- 4 Aspirations and Intentions
- 5 Milestones, Release Candidates, and Service Releases
- 6 Participating Projects
- 7 Helium Project Dependency Diagram
- 8 Decision on the Use of Karaf for Feature Selection Within Helium
- 9 Status
- 10 Communication Channels
- 11 Proposed Release Vehicles
- 12 Service Release Recommendations
- 13 Addendum
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
- Projects must declare their intent to participate in the Simultaneous Release by M1.
- Participating projects must publish a candidate Release Plan by M1 and declare their Release Plan by M2
- Participating project Release Plans must contain Milestones that minimally line up with the Simultaneous Release Plan Milestones
- Modules that are not intended to interface with the controller via REST/other rpc mechanism must be OSGI bundles
- OSGI bundles should be reasonably granular
- 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)
- No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repo.
- Code Hygiene
- No uses of System.out.println in non testcase code.
- 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.
- Continuous Release - The automated cutting of a regular set of release artifacts from each project (expected to be weekly).
- 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.
|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.
|RC2||9/22/2014||Participating Projects must hold their Release Reviews, including User Facing Documentation.|
|Formal Helium Release||9/29/2014||
|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.
|Project||Release Plan||Contact||Contact Email||Contact IRC Nick|
|AAA Service||Release Plan||Liem Nguyenfirstname.lastname@example.org||liemmn|
|Controller||Release Plan||Ed Warnickeemail@example.com||edwarnicke|
|dLux||Release Plan||Harman Singh (harmasin)||firstname.lastname@example.org||harmasin|
|Docs||Release Plan||Manny Setemail@example.com||manny|
|Group Based Policy||Release Plan||Keith Burnsfirstname.lastname@example.org||alagalah|
|Integration Group||Release Plan||Luis Gomezemail@example.com||LuisGomez|
|L2 Switch||Release Plan||
|Lisp Flow Mapping Service||Release Plan|| Vina Ermagan
|ODL-SDNi App||Release Plan||Rafat Jahanfirstname.lastname@example.org||rafat|
|OpenFlow Plugin||Release Plan||Abhijit Kumbhareemail@example.com||abhijitkumbhare|
|Openflow Protocol Library||Release Plan||Michal Polkorabfirstname.lastname@example.org||oflibMichal|
|PacketCablePCMM||Release Plan||Thomas Keeemail@example.com||xsited|
|Secure Network Bootstrapping Infrastructure||Release Plan||Frank Brocknersfirstname.lastname@example.org||brockners|
|Service Function Chaining||Release Plan||Paul Quinnemail@example.com||paulq|
|Southbound plugin to the OpenContrail platform||Release Plan||Priyanka Choprafirstname.lastname@example.org||PriyankaChopra|
|SNMP4SDN||Release Plan||Yi-Ling (Christine) Hsiehemail@example.com||ChristineH|
|Table Type Patterns||Release Plan||Colin Dixonfirstname.lastname@example.org||colindixon|
|TCP-MD5||Release Plan||Robert Vargaemail@example.com||rovarga|
|VTN Project||Release Plan||
|YANG Tools||Release Plan||Tony Tkacikfirstname.lastname@example.org||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
- Mathieu Lemay provided information on Karaf Packaging on July 23rd.
- Luis Gomez provided information on Testing needs in a Karaf environment during the TWS call on July 28th
OpenDaylight Status Spreadsheet: direct link to sheet
email@example.com is the formal channel for communication about the Simultaneous Release.
firstname.lastname@example.org is the developer's discussion channel for communication about the Simultaneous Release.
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
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