|
|
| (14 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | =Overview=
| + | This page's content has been moved to the [https://www.eclipse.org/projects/handbook/#release Eclipse Project Handbook]. |
| − | [[Image:ReleaseCycle.png|center]]
| + | |
| − | | + | |
| − | # A release starts with planning.
| + | |
| − | #* Create a [[Project Management Infrastructure/Project Metadata#Releases|release record]] at the beginning of the release cycle.
| + | |
| − | #** You can create as many future release records as you'd like.
| + | |
| − | #* Capture the [[Development Resources/Project Plan|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)
| + | |
| − | # 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
| + | |
| − | #** See [[Development Resources/Handling Git Contributions|Handling Git/Gerrit contributions]]
| + | |
| − | # 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 review]]
| + | |
| − | #** Release reviews are not required for bug-fix/service releases
| + | |
| − | #* Send a note to [mailto:emo@eclipse.org 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
| + | |
| − | | + | |
| − | =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.
| + | |
| − | | + | |
| − | [[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
| + | |
| − | #* You can assemble this during the release cycle (there's no need to wait until the end)
| + | |
| − | # Assemble the IP Log
| + | |
| − | #* [[Development Resources/IP Log|IP Logs]] are [[Development Resources/Automatic IP Log|generated automatically]] using project data.
| + | |
| − | #** If you consistently follow the IP Policy, then assembling the IP Log should require no dedicated effort.
| + | |
| − | #* [[Development Resources/Contribution Questionnaire|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)
| + | |
| − | # Submit 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 [mailto:emo@eclipse.org 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.
| + | |
| − | # 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.
| + | |
