Oxygen Simultaneous Release Open

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

1. 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.³

1. Participating Projects must have declared their final Release Plan with all sections fully completed.
2. Projects that need extra configuration or resources other than those available in the OpenDaylight CI infrastructure must have opened helpdesk tickets to add them.
3. Project Checklist completed (for all projects, not just new ones).
4. 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.
5. 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.
6. Project must get acknowledged from all projects that it depends on.

1. Feature/Functionality Freeze
   • Final list of externally consumable APIs defined and documented
     • Projects must state for each TENTATIVE API they have (if any) whether they are formally planning to deliver it.
       • If so, it should be noted that it will be delivered.
       • If not projects requesting the API must be informed so that they can take corrective actions.
     • Externally consumable APIs are available at beta-quality
   • All inter-project dependencies are resolved (all project functionality is declared as either "In" or "Out" of this release)
2. Karaf Features defined
   • Instructions can be found in the Karaf:Step by Step Guide
     • Each feature should be tested in every appropriate jenkins job (at least -verify, -merge, and -integration) using the "SingleFeatureTest" as defined 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
     • Projects must have a distribution job to verify changes in code do not impact the integration distribution (this will be automatically setup by the releng/builder group).
   • 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:
     • Each "top-level" feature must have a developer guide section (See the documentation requirements section above) and a system test (See the integration and test requirements section above).
     • Each "user-facing" feature must have a user guide section (See the documentation requirements section above)
     • Each "stable" feature must meet the requirements explained in the definitions section above.
   • Changing the name of a Karaf feature or removing a Karaf feature should be handled via an API freeze waiver after this point
3. 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.)
4. Feature Test Started
   • Instructions can be found in the System Test Step by Step Guide.
   • Projects must have filled out a basic system test plan template for each top-level feature (karaf and not karaf). Stable features have additional requirements for functionality, cluster, scalability, performance, longevity/stability.

1. API Freeze: See more information in the definition above.
2. Documentation:
   • Project readouts MUST include a word count of each relevant .adoc file with a goal of draft documentation done.
3. Projects are encouraged to meet the requirements to be included in maven central
   • Project readout MUST include whether or not this was accomplished
4. Feature Test Continues
   • Participating projects Projects must have all extra SW configuration and resources required for system test installed in the OpenDaylight CI⁴. More information in How To Install SW in CI.

1. Code Freeze (bug fixes only from here as defined above)
2. Stability branch, i.e., stable/oxygen, must be cut and local project versions bumped on master to avoid overwriting Oxygen SNAPSHOTS
   • Follow steps 1–4 from the instructions on cutting stability branches
   • Note: Branch cutting will occur sometime between offset 0 M4 and offset 2 M4 and may be either staggered by offsets or done all at once. See TSC meeting minutes from 7/9/2015 item 5.ac.
3. String Freeze (all externally visible strings frozen to allow for translation & documentation)
4. Documentation Complete: Only editing and and enhancing should take place after this point.
5. 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 feature⁴.

1. The build for RC0 will start at 23:59:59 UTC
   • At the start of the build for RC0, all projects must be in the distribution and autorelease.
     • Between M4 for offset 2 projects and RC0 is a two week period for projects to finish adding to Oxygen Integration Distribution and Oxygen Autorelease and for projects to fix any errors in the Oxygen Autorelease Jenkins Build Job. At the beginning of this two week period, projects are given two week notice of potential drop. Projects that have not been successfully added to the Integration Distribution and Autorelease are dropped from the release. At the end of this two week period, we release RC0 for projects to begin their initial testing. At this time, all projects participating in the release must be in the distribution and autorelease.
2. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues
3. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet

1. The build for RC1 will start at 23:59:59 UTC
   • At the start of the build for RC1, all stable/oxygen branches will be locked and only release engineering staff will be able to merge patches.
2. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues
3. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet

1. The build for RC2 will start at 23:59:59 UTC
   • At the start of the build for RC2, the release engineering staff will only merge patches that fix blocking bugs. 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.
2. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues
3. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet

1. Participating Projects must hold their Release Reviews, including User Facing Documentation.
   • The release review should be based on the Sample Release Review and should point to release notes based on Sample Release Notes.
2. The build for RC3 will start at 23:59:59 UTC
3. 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.
4. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues
5. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet

1. Formal Oxygen Release
   • NOTE: The build to produce the formal release artifacts is likely to occur before the formal release date.
2. 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.

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

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

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

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

BIER/BIER-TE BierMan

BFR nodes & BIER-TE topology configuration and storage

Tentative

Provisional

Stable

bier-topology.yang

bierman

BIER/BIER-TE Channel

BIER-TE channel configuration and storage

Tentative

Provisional

Stable

bier-channel.yang

channel

BIER/BIER-TE OAM

BIER/BIER-TE Oam configuration and storage

Tentative

Provisional

Stable

bier-oam.yang

oam

BIER-TE FRR

BIER-TE frr configuration and storage

Tentative

Provisional

Stable

bier-frr.yang

bierman/service