Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Development Resources/HOWTO/Release Cycle"
(→Release Review) |
|||
Line 27: | Line 27: | ||
=Release Review= | =Release Review= | ||
[[Image:ReleaseReview.png|center]] | [[Image:ReleaseReview.png|center]] | ||
+ | |||
+ | # Assemble review documentation | ||
+ | #* Concise documentation is appreciated by everybody | ||
+ | #* Capture the review information directly in the [[Project Management Infrastructure/Release Metadata|release record]]. | ||
+ | #** Alternatively, you can provide a separate document (e.g. PowerPoint presentation) if you must |
Revision as of 12:08, 18 October 2013
Overview
- A release starts with planning.
- Create a release record at the beginning of the release cycle.
- You can create as many future release records as you'd like.
- Capture the project plan directly in the release record.
- Alternatively, you can use the older XML-file format if you must.
- The plan doesn't need to be particularly detailed, but it does need to exist.
- The plan should lay out in broad terms what the goals are for the release.
- Set a date. The date can change.
- Provide a concise (i.e. one paragraph, no bullets) description for the release.
- Capture at least one theme for the release (this could be as simple as "Fix bugs")
- The plan can change during the release cycle (please inform your project's community when you change the plan)
- Create a release record at the beginning of the release cycle.
- Implement functionality
- Ensure that all committers are aware of the Eclipse IP Policy and Eclipse Development Process
- Ensure that intellectual property contributions are being tracked
- Produce milestone
- Generate regular builds of the project and host them on your project's download site
- Release
- For all major/minor releases, you must engage in a release review
- Release reviews are not required for bug-fix/service releases
- Send a note to EMO to request a release review
- When the release review has been declared successful by the EMO, generate your final build (or rename a previous RC/M build) and host them on your project's download site
- For all major/minor releases, you must engage in a release review
Release Review
- Assemble review documentation
- Concise documentation is appreciated by everybody
- Capture the review information directly in the release record.
- Alternatively, you can provide a separate document (e.g. PowerPoint presentation) if you must