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) |
(→Release Review) |
||
Line 42: | Line 42: | ||
#* Contribution information is harvested directly from the project's source code repositories. | #* Contribution information is harvested directly from the project's source code repositories. | ||
#* The information used to generate an IP Log should always be up-to-date (don't wait until the end of the release cycle to make it right) | #* The information used to generate an IP Log should always be up-to-date (don't wait until the end of the release cycle to make it right) | ||
− | # Submit IP Log | + | # Submit the IP Log |
#* Do this at least one week in advance of the start of the review period | #* Do this at least one week in advance of the start of the review period | ||
#* The IP Log Generator has a "submit" button. Click it. | #* The IP Log Generator has a "submit" button. Click it. |
Revision as of 12:25, 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
Release reviews run for a week and always conclude on a Wednesday. We normally schedule no more than two review periods each month.
- 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
- You can assemble this during the release cycle (there's no need to wait until the end)
- Assemble the IP Log
- IP Logs are generated automatically using project data.
- If you consistently follow the IP Policy, then assembling the IP Log should require no dedicated effort.
- Contribution questionnaire data is harvested directly from IPZilla.
- Contribution information is harvested directly from the project's source code repositories.
- The information used to generate an IP Log should always be up-to-date (don't wait until the end of the release cycle to make it right)
- IP Logs are generated automatically using project data.
- Submit the IP Log
- Do this at least one week in advance of the start of the review period
- The IP Log Generator has a "submit" button. Click it.
- PMC Review
- Send an email to your PMC via their public mailing list to request approval of the review documentation
- One week in advance of the start of the review period may be a little excessive; most PMCs can turn this around in short order. Still, it's good to give them some advance notice and time to complete the task.
- The requirements for approval varies from PMC-to-PMC, but for most PMCs, a single +1 is all you need.
- Send a note to EMO with a link to the mailing list discussion showing PMC approval.
- Start the release review
- A review will be scheduled when the following is received by the EMO:
- Proof of PMC approval of the review documentation; and
- Approval of the IP Log from the IP Team.
- The EMO will schedule review and announce it to the community.
- A review will be scheduled when the following is received by the EMO:
- End Release Review
- Release reviews end on Wednesdays (generally late morning in the eastern time zone).
- Wait for an approval notice
- Publish your release
- Generate your final release bits.
- Tell the world.