...
- Milestones are spaced roughly 4 weeks apart taking into account significant holidays.
- Release Candidates (RC) are spaced roughly 1 week apart
- Service Releases are roughly 4, 12, 20, and 30 weeks after the Formal Release and are intended to continue at least until the after the next formal release of the TF, presumably .
Milestones
- M0 - Contact FreezeIncrement blueprint approved, contact freeze
- M1 - Dependencies between projects/features clarifications, final Release Plans for projects fully defined
- M2 - Functionality Freeze: (used to be called feature freeze) No new externally visible functionality is to be added to the current release of TF. All provisional APIs are at least functional (at a beta-quality level) if not yet fully tested.
- M3 - API Freeze (M3): All externally accessible APIs (Stable and Provisional) may not be modified. An API exception process will allow for critical changes to APIs after API freeze with the consent of the consuming projects.
- M4 - Code Freeze (M4): No new features/functionality are to be allowed into the current release. Only errors/bugs identified in the bug system are allowed. The exceptions to this include new tests, and documentation. Distribution packaging must be complete. Errors/bugs found after Code Freeze are still bugs and they may be created and worked on. This includes packaging bugs found as well.
- M4 - String Freeze (M4): All text strings used within TF may not be changed. Final documentation and localization teams may rely on these strings not changing for the current release.
- Release Candidate (RCRC1-RC3): A fully-built, complete version of the current TF release. This includes all code, documentation, and packaging that make up the final user-deliverable set of artifacts. After RC0, new RCs will be continually built, e.g., once per day, to enable rapid testing and fixing of bugs.
- Note that this definition makes the dates for RCs and the final release as targets, but they may need to be adjusted based on project readiness and any remaining blocking bugs.
- While we will build daily release candidates, the notion of RC#s (increasing in number at a longer cadence, e.g., weekly) will remain to aid in planning when bug fixes are expected.
- During the RC process blocking bugs will be tracked both on a spreadsheet and in JIRA.
- During the RC process regular, e.g., daily, meetings may be held on IRC to identify and address critical issues as they arise.
- Projects not in the autorelease and the distribution feature index by RC0 cutoff will be dropped from the release.
...