Skip to main content
Jump to: navigation, search

Development Resources/HOWTO/Release Cycle

< Development Resources
Revision as of 12:24, 18 October 2013 by (Talk | contribs) (Release Review)


  1. 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)
  2. 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
  3. Produce milestone
    • Generate regular builds of the project and host them on your project's download site
  4. 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

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.

  1. 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)
  2. 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)
  3. 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.
  4. 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.
  5. 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.
  6. End Release Review
    • Release reviews end on Wednesdays (generally late morning in the eastern time zone).
    • Wait for an approval notice
  7. Publish your release
    • Generate your final release bits.
    • Tell the world.

Back to the top