Jump to: navigation, search

TM/3.2 Release Checklist

< TM

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
    • Ok green.gif Update Copyright Year and Release Version where necessary
    • Ok green.gif Must not have any broken hyperlinks
    • See also ISV doc checklist and code checklist
  6. User Documentation
    • Docs contain no outdated information
    • Update Screenshots where necessary
    • Ok green.gif Update Copyright Year and Release Version where necessary
    • Ok green.gif 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. Ok green.gif Make sure all bugs with patches have the iplog+ flag set [Martin]
  11. Ok green.gif 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
    • Ok green.gif Importing plugin with source from CVS works (randomly test a couple of plugins)
    • Ok green.gif Importing plugin with source from Target Platform does not produce compile errors (randomly test a couple of plugins)
    • Ok green.gif Running Unittests from rse.tests plugin imported as source from the target platform works
  14. Ok green.gif Unittests
    • All known Unittest Failures must have an associated bugzilla entry
  15. Test installing from update site on reference platforms
    • Test updating 3.1 to 3.2 on one reference platform
    • Test installing / running on minimal target (Platform runtime only without JDT or CDT; J2SE-1.4 only)
  16. Ok green.gif Enable Equinox p2 download stats
    • Review / Update DL Stat version identification
    • Local TM Repo: /stats/dsdp/tm/org.eclipse.rse.*_tm320
    • Helios Repo: /stats/releases/helios/org.eclipse.rse.*_tm320
    • ZIP Downloads: /dsdp/tm/downloads/drops/R-3.2-
  17. Release Train Contribution
    • Ensure train contribution comes from a "staging" site with download stats enabled
    • Test installing / updating from train staging site
    • Verify download stats being generated
  18. Ok green.gif Clean-up Bugzilla Target Milestones
  19. Ok green.gif Produce the release review documentation [Martin]
  20. Ok green.gif Run PDE Tools > Organize Manifests... to ensure all packages are exported with x-internal according to API status
  21. Ensure that Project Set Files (.PSF) contain all projects / plugins / features needed for adopters
  22. Prepare for the Helios/Final Daze
  23. Ok green.gifAt Release Time: Tag the CVS and SVN Repositories with the R3_2 release identifier
    • TM: R3_2, TCF: tags/0.3.0