| | |
|---|
M0 | 9/7/2017 | Oxygen Simultaneous Release Open Contact Freeze Projects must have declared intent to participate in Simultaneous Release Projects must have elected their Project Leads and specify a Test Contact Participating Projects must have published a candidate Release Plan for public comment ( Release Plan Template )
Note: the date for M0 will normally be at least one day after the TSC approves the Oxygen release plan. Note that the release plan includes details about negotiating inter-project dependencies, expectations, and incompatibilities.
|
Last call for project proposals | 9/28/2017 | This is the latest date a project proposal can be sent to the project-proposals list and still have the required two week public comment period before its project creation review at the last TSC meeting before the M1/M2/M3 milestone. Project proposals submitted after this date will not be able to become formal projects by M1/M2/M3 and thus will not be able to participate in the Oxygen release.3
|
M1 | 10/21/2017 | Participating Projects must have declared their final Release Plan with all sections fully completed. Projects that need extra configuration or resources other than those available in the OpenDaylight CI infrastructure must have opened helpdesk tickets to add them. Project Checklist completed (for all projects, not just new ones). Projects may apply for a system test waiver if they think they have top-level features not requiring system test or covered by other top-level features test. Projects must specify whether they plan to use OpenDaylight CI infrastructure for system test. It is recommended to use the OpenDaylight CI infrastructure unless there is some HW or SW resource that cannot be installed there. Projects running system test in external Labs are required to report system test results in a timely fashion after release creations, e.g., weekly, RC, and formal releases. Project must get acknowledged from all projects that it depends on.
|
M2 | 11/21/2017 | Feature/Functionality Freeze Karaf Features defined Instructions can be found in the Karaf:Step by Step Guide Any feature repositories containing features intended for release must be added to the main features.xml file in the integration git repository as explained in the Karaf step-by-step guide Features that are intended to be "top-level", "user-facing" and/or "stable" must be called out in the milestone readout. These features will have additional requirements: Changing the name of a Karaf feature or removing a Karaf feature should be handled via an API freeze waiver after this point
Documentation Started Identified the kinds of documentation to be provided, created AsciiDoc files for them with outlines, and committed those files in an appropriate location. (See the documentation requirements section above for more details.)
Feature Test Started
|
M3 | 12/21/2017 | API Freeze: See more information in the definition above. Documentation: Projects are encouraged to meet the requirements to be included in maven central Feature Test Continues
|
M4 | 1/21/2018 | Code Freeze (bug fixes only from here as defined above) Stability branch, i.e., stable/oxygen, must be cut and local project versions bumped on master to avoid overwriting Oxygen SNAPSHOTS String Freeze (all externally visible strings frozen to allow for translation & documentation) Documentation Complete: Only editing and and enhancing should take place after this point. Feature Test Complete Stable features should fulfill quality requirements listed in definitions section Projects must run at least one basic automated system test job for each top-level feature and several automated system test jobs including functionality, cluster, scalability, performance, longevity/stability for each stable feature4.
|
RC0 | 2/7/2018 | The build for RC0 will start at 23:59:59 UTC During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
RC1 | 2/14/2018 | The build for RC1 will start at 23:59:59 UTC During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
RC2 | 2/21/2018 | The build for RC2 will start at 23:59:59 UTC During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
RC3 | 2/28/2018 | Participating Projects must hold their Release Reviews, including User Facing Documentation. The build for RC3 will start at 23:59:59 UTC All stable/oxygen branches will remain locked and only release engineering staff will be able to merge patches and will only do so for patches that fix blocking bugs. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
Formal Oxygen Release | 3/7/2018 | Formal Oxygen Release After the release, except for projects that have opted-out, the release engineering staff will apply the release patch to the stable/oxygen branch and bump versions. Note: Any patches merged to stable/oxygen after the auto-release build that produces the formal release artifacts, but before the release patch and version bumps are applied will have to be reverted and re-applied after the release and version bump patches. This shouldn't happen in Oxygen as the stable/oxygen branches will have been locked since RC1.
|
SR1 (Service Release 1 aka Oxygen.1) | 4/7/2018 | First Service Release for Oxygen. 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. To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release. Blocking bugs will be tracked via bugzilla and a spreadsheet.
After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release.
|
SR2 (Service Release 2 aka Oxygen.2) | 6/7/2018 | Second Service Release for Oxygen. 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. To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release. Blocking bugs will be tracked via bugzilla and a spreadsheet.
After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release.
|
SR3 (Service Release 3 aka Oxygen.3) | 8/7/2018 | Third Service Release for Oxygen. 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. To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release. Blocking bugs will be tracked via bugzilla and a spreadsheet.
After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release.
|
SR4 (Service Release 4 aka Oxygen.4) | 9/21-11/7 | Fourth Service Release for Oxygen. 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. To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release. Blocking bugs will be tracked via bugzilla and a spreadsheet.
After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release.
|