...
3.3.2.3. The project lifecycle process does not impose a duration for the project nor for the release. There is an independent Release Plan document for each release to specify release timelines.timelines which includes, but is not limited to the following: NUMBERING NEEDS TO BE FIXED
3.3.7.1. Release Plan
3.3.7.1.1. Introduction
3.3.7.1.2. Release Deliverables
3.3.7.1.3. Release Milestones
3.3.7.1.4. Expected Dependencies on Other Projects
3.3.7.1.5. Compatibility with Previous Release
3.3.7.1.6. Themes and Priorities
3.3.7.1.7. Other
3.3.7.1.8. Features delivered
3.3.7.1.9. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.7.1.10. Architectural Issues (if any)
3.3.7.1.11. Security Issues (if any)
3.3.7.1.12. Quality Assurance (test coverage, etc)
3.3.7.1.13. End-of-life (API/Features EOLed in Release)
3.3.7.1.14. Summary of Outstanding Bugs
3.3.7.1.15. Summary of Standards Compliance
3.3.7.1.16. Delta between planned schedule and actual schedule
3.3.7.2. Release Review
3.3.7.2.1. Features delivered
3.3.7.2.2. Non-Code Aspects (user docs, examples, tutorials, articles)\
3.3.7.2.3. Architectural Issues (if any)
3.3.7.2.4. Security Issues (if any)
3.3.7.2.5. Quality Assurance (test coverage, etc)
3.3.7.2.6. End-of-life (API/Features EOLed in Release)
3.3.7.2.7. Summary of Outstanding Bugs
3.3.7.2.8. Summary of Standards Compliance
3.3.7.2.9. Delta between planned schedule and actual schedule
3.3.3. Project Lifecycle States and Reviews
...
The process of managing this review state can be found here
3.3.7. Mature Release Process
A Project’s Committers make all decisions about Releases of that Project. However However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process. The The purpose of the Mature Release Process is to ensure openness and maximum opportunity for participation. The The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle. Towards Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.
Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist the project in coordinating among themselves and the general world in gaining visibility.
These should contain roughly the following sections:
3.3.7.1. Release Plan
3.3.7.1.1. Introduction Introduction
3.3.7.1.2. Release Release Deliverables
3.3.7.1.3. Release Release Milestones
3.3.7.1.4. Expected Expected Dependencies on Other Projects
3.3.7.1.5. Compatibility Compatibility with Previous Release
3.3.7.1.6. Themes Themes and Priorities
3.3.7.1.7. Other Other
3.3.7.1.8. Features Features delivered
3.3.7.1.9. Non Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.7.1.10. Architectural Architectural Issues (if any)
3.3.7.1.11. Security Security Issues (if any)
3.3.7.1.12. Quality Quality Assurance (test coverage, etc etc)
3.3.7.1.13. End End-of-life (API/Features EOLed in Features EOLed in Release)
3.3.7.1.14. Summary Summary of Outstanding Bugs
3.3.7.1.15. Summary Summary of Standards Compliance
3.3.7.1.16. Delta Delta between planned schedule and actual schedule
3.3.7.2. Release Review
3.3.7.2.1. Features Features delivered
3.3.7.2.2. Non Non-Code Aspects (user docs, examples, tutorials, articles articles)\
3.3.7.2.3. Architectural Architectural Issues (if any)
3.3.7.2.4. Security Security Issues (if any)
3.3.7.2.5. Quality Quality Assurance (test coverage, etc etc)
3.3.7.2.6. End End-of-life (API/Features EOLed in Features EOLed in Release)
3.3.7.2.7. Summary Summary of Outstanding Bugs
3.3.7.2.8. Summary Summary of Standards Compliance
3.3.7.2.9. Delta Delta between planned schedule and actual schedule