Skip to main content
Jump to: navigation, search

TM/3.2 Release Checklist

This checklist is used to ensure that no important cleanup work is forgotten preparing releases. Its content is aligned with the Eclipse/Release checklist in use by the Platform.

  1. Ok green.gif Copyright notices [Martin]
    • Ok green.gif All source files must have appropriate EPL v1.0 copyright notice
    • Ok green.gif Source files whose content was created in this release should read "Copyright (c)  2009 ..." or "Copyright (c)  2010 ..."
    • Ok green.gif Source files whose content was modified during this release should read "Copyright (c)  200x, 2009 ..." or "Copyright (c)  200x, 2010 ..."
    • Ok green.gif The about dialog content for each feature (which is provided by its associated branding plugin) has a proper release version identification, Copyright Owner, Copyright year and 3rd party license notices as required (e.g. by included Apache plugins).
  2. Ok green.gif Plug-in and feature identification [Martin]
    • Check the info in Help > About Eclipse SDK
    • Ok green.gif All features should have provider "Eclipse.org - DSDP" and a version that adheres to the Version Numbering guidelines.
    • Ok green.gif All plug-ins should have provider "Eclipse.org - DSDP" and version as per the Version Numbering guidelines, except for known special cases (org.apache.*, org.junit, and bundles from Orbit).
  3. License agreements for features and plug-ins [Martin]
    • Help > About Eclipse SDK > {Feature | Plug-in} Details > More Info
    • Ok green.gif All features should link to the Eclipse Foundation Software User Agreement dated April 14, 2010
    • All plug-ins should link to the plug-in's about.html file containing its plug-in-specific license
  4. Extension point documentation
    • Extension points must be documented in the appropriate help book
    • Must be a link to each extension point that a component has
    • Extension points added in this release must be clearly marked "Since x.y" where x.y is the project release number
    • See also ISV doc checklist
  5. API documentation
    • Java API must be documented in the appropriate help book
    • Must be a link to each API package that a component has
    • API package must have package overview (package.html)
    • All API elements must be documented
    • API elements added in this release must be tagged "@since x.y" where x.y is the bundle version number
    • Fulltext Search of API must create / use the help index without errors, and must produce hits in the documentation
    • Update Copyright Year and Release Version where necessary
    • See also ISV doc checklist and code checklist
  6. User Documentation
    • Docs contain no outdated information
    • Update Screenshots where necessary
    • Update Copyright Year and Release Version where necessary
    • Must not have any broken hyperlinks
    • See User doc checklist
  7. Ok green.gif API Compatibility [Martin]
    • Make sure that the 'API Tools Version Verification Report' lists no compatibility and no bundle version warning for your bundles
    • Verify that the 'API Tools Post-API Freeze Report' has no entries
  8. Plug-in Migration Guide
    • Instructions for migrating older plug-ins to current release
    • Must describe incompatibilities and breaking API changes
    • Should describe deprecations and places where current release has a better story that plug-ins should more to
  9. What's New
    • Describes the more interesting differences that users will see when they upgrade to the latest release
  10. Make sure all bugs with patches have the iplog+ flag set
  11. Submit the IP Log to Eclipse Legal [Martin]
  12. Eclipse Project Release Notes
    • Add known problems for each component and other late-breaking news for customers of this release
    • See bug 313131 for details
    • Update other sections of readme based on current release plan
  13. Verify that source is included in all SDK features
    • Importing plugin with source from CVS works (randomly test a couple of plugins)
    • Importing plugin with source from Target Platform does not produce compile errors (randomly test a couple of plugins)
    • Running Unittests from rse.tests plugin imported as source from the target platform works
  14. Unittests
    • Any known Unittest Failure has an associated bugzilla entry
  15. Test installing from update site on reference platforms
    • Test updating 3.1 to 3.2 on reference platforms
  16. Clean-up Bugzilla Target Milestones
  17. Produce the release review documentation [Martin]

Back to the top