| | |
|---|
M0/M1 | 6/21/2017 | Nitrogen 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 be at least one day after the TSC approves the Nitrogen release plan.
|
last call for project proposals | 6/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 M2/M3/M4 milestone. Project proposals submitted after this date will not be able to become formal projects by M2/M3/M4 and thus will not be able to participate in the Nitrogen release.3
|
M2/M3/M4 | 7/14/2017 | API Freeze: See more information in the definition above. Note that the release plan includes details about negotiating inter-project dependencies, expectations, and incompatibilities. Plan Freeze Participating Projects must have declared their final Release Plan with all sections fully completed. Projects that need extra configuration or resources other than those availble 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.
Feature/Functionality Freeze API Freeze: See more information in the definition above.
|
M5 | 8/14/2017 | Code Freeze (bug fixes only from here as defined above) Stability branch, i.e., stable/nitrogen, must be cut and local project versions bumped on master to avoid overwriting Nitrogen 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 | N/A | The build for RC1 will start at 23:59:59 UTC During the RC process, regular, e.g., daily, IRC meetings will take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
RC1 | N/A | The build for RC1 will start at 23:59:59 UTC All stable/nitrogen 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 will take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
RC2 | N/A | The build for RC2 will start at 23:59:59 UTC All stable/nitrogen 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 will take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
RC3 | N/A | Participating Projects must hold their Release Reviews, including User Facing Documentation. The version suffix for RC3 will be -Nitrogen instead of -Nitrogen-RCX or -Nitrogen-RCX-<timestamp> so that the build can be released if it is found to be free of blocking bugs. The build for RC3 will start at 23:59:59 UTC All stable/nitrogen 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 will take place to identify and address issues During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
|
Formal Nitrogen Release | N/A | Formal Nitrogen Release After the release, except for projects that have opted-out, the release engineering staff will apply the release patch to the stable/nitrogen branch and bump versions. Note: Any patches merged to stable/nitrogen 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 Nitrogen as the stable/nitrogen branches will have been locked since RC0.
|
SR1 (Service Release 1 aka Nitrogen.1) | N/A | First Service Release for Nitrogen. 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/nitrogen 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 Nitrogen.2) | N/A | Second Service Release for Nitrogen. 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/nitrogen 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 Nitrogen.3) | N/A | Third Service Release for Nitrogen. 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/nitrogen 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 Nitrogen.4) | N/A | Fourth Service Release for Nitrogen. 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/nitrogen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release.
|