Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Development Resources/HOWTO/Release Cycle

< Development Resources
Revision as of 12:33, 18 October 2013 by Wayne.eclipse.org (Talk | contribs) (Release Review)

Overview

ReleaseCycle.png
  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.

ReleaseReview.png
  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).
    • Use the Project Downloads Scanner Tool to confirm that your project downloads contain only approved third-party code
      • This tool was designed to scan OSGi bundles; it may not produce good results for standard Java JARs or builds based on other programming languages.
      • The tool displays the output from a service that runs daily; new additions to your project's download directory may take as much as 24 hours to appear.
    • Use the Bugzilla Contribution Review Tool to identify Bugzilla records that may contain IP that needs to be tracked. Projects that use Git and follow the guidelines for handling Git contributions will not get much value out of this tool.
  3. 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.
  4. 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.
  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.

Please see more detailed information about Release Reviews, including the checklist.

Back to the top