Jump to: navigation, search

Difference between revisions of "Development Resources/HOWTO/Release Cycle"

(Release Review)
(Overview)
Line 3: Line 3:
  
 
# A release starts with planning.
 
# A release starts with planning.
#* Create a [[Project Management Infrastructure/Release Metadata|release record]] at the beginning of the release cycle.
+
#* 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.
 
#** 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.
 
#* Capture the [[Development Resources/Project Plan|project plan]] directly in the release record.

Revision as of 11:09, 18 October 2013

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

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