This is the latest date a project increment proposal can be sent to the TSC and still have the required two week public comment period before its review at the last TSC meeting before the M0 milestone. Project increment proposals submitted after this date will not be able to become formally included in the planned simultaneous release. Such a project increment, however, may still be considered for the next release.

• Participating Projects must have published an initial Increment blueprint for public comment
• Participating Projects must have update the initial Release Scope Overview

Date

N/A

N/A

Simultaneous Release Scope agreed, approved

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 - Project charter updated
2. Scope of release approved
   • Participating Projects must have published, discussed, approved by TSC an Increment blueprint 
   • Participating Projects must have published a candidate Release Plan for public comment ( Release Plan Template - TO BE DEFINED )
   • Release Scope Overview updated, approved by TSC

Release Plan agreed, approved

1. Participating Projects must have declared their final Increment blueprint and the Release Plan with all sections fully completed.
2. Projects that need extra configuration or resources other than those available in the TF 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 TF CI infrastructure for system test. It is recommended to use the TF 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. The project must get acknowledged from all projects that it depends on.

• Note: the date for M1 will normally be at least one day after the TSC approves the  release plan.
• Note that the release plan includes details about negotiating inter-project dependencies, expectations, and incompatibilities.

Feature Freeze

1. Functionality Freeze
   • 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
• Final list of externally consumable APIs defined and documented
• All inter-project dependencies are resolved (all project functionality is declared as either "In" or "Out" of this release)
2. Features defined
   • 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).
   • Each "top-level" feature must have a developer guide section and a system test Each "user-facing" feature must have a user guide section Each "stable" feature must meet the requirements explained in the definitions section above.
• Each feature should be tested in every appropriate jenkins job (at least -verify, -merge, and -integration)
• 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 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 feature or removing a feature should be handled via an API freeze waiver after this point
3. Documentation Started
• Identified the kinds of documentation to be provided, created docs files for them with outlines, and committed those files in an appropriate location. 
4. Feature Test Started
• Instructions can be found in the System Test Step by Step Guide (TBD).
• Projects must have filled out a basic system test plan template for each top-level feature. Stable features have additional requirements for functionality, cluster, scalability, performance, longevity/stability.

API Freeze

1. API Freeze: See more information in the definition above.
2. Documentation:
• Project readouts MUST include a word count of each relevant doc file with a goal of draft documentation done.
3. Feature Test Continues
• Participating projects Projects must have all extra SW configuration and resources required for system test installed in the TF CI. 

Code Freeze

1. Code Freeze (bug fixes only from here as defined above)
2. Stability branch, i.e., stable/, must be cut and local project versions bumped on master to avoid overwriting  SNAPSHOTS
• 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.
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.

Release Candidates Freeze

1. The build for RC0 will start at 23:59:59 UTC
   • Between M4 for offset 2 projects and RC0 is a two week period for projects to finish adding to  Integration Distribution and Autorelease and for projects to fix any errors in the Autorelease 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.
• At the start of the build for RC0, all projects must be in the distribution and autorelease.
2. During the RC process, regular, e.g., daily, meetings may take place to identify and address issues
3. During the RC process, blocking bugs will be tracked in JIRA 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/ branches will be locked and only release engineering staff will be able to merge patches.
2. During the RC process, regular, e.g., daily, meetings may take place to identify and address issues
3. During the RC process, blocking bugs will be tracked in JIRA 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/ 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, meetings may take place to identify and address issues
3. During the RC process, blocking bugs will be tracked in JIRA and a common spreadsheet

1. Participating Projects must hold their Release Reviews, including User Facing Documentation.
• The build for RC3 will start at 23:59:59 UTC
2. All stable/ 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.
3. During the RC process, regular, e.g., daily, meetings may take place to identify and address issues
4. During the RC process, blocking bugs will be tracked in JIRA and a common spreadsheet

1. Formal  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/ branch and bump versions.
• Note: Any patches merged to stable/ 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  as the stable/ branches will have been locked since RC1.

1. First Service Release for . 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 JIRA and a spreadsheet.
2. After the release, projects MUST apply the release patch to the stable/ 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/ 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 . 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 JIRA and a spreadsheet.
2. After the release, projects MUST apply the release patch to the stable/ 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/ 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 . 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 JIRA and a spreadsheet.
2. After the release, projects MUST apply the release patch to the stable/ 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/ 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 . 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 JIRA and a spreadsheet.
2. After the release, projects MUST apply the release patch to the stable/ 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/ 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.