Difference between revisions of "TM/3.2 Release Checklist"

Latest revision as of 05:23, 25 February 2011

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. Copyright notices [Martin]
   • All source files must have appropriate EPL v1.0 copyright notice
   • Source files whose content was created in this release should read "Copyright (c)  2009 ..." or "Copyright (c)  2010 ..."
   • Source files whose content was modified during this release should read "Copyright (c)  200x, 2009 ..." or "Copyright (c)  200x, 2010 ..."
   • 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. Plug-in and feature identification [Martin]
   • Check the info in Help > About Eclipse SDK
   • All features should have provider "Eclipse.org - DSDP" and a version that adheres to the Version Numbering guidelines.
   • 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
   • 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
     • RSE Developer Guide / Reference / Extension Points Reference
   • 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
     • RSE Developer Guide / Reference / Remote Systems API Reference All Packages as well as Reference by Topic
     • RSE DStore Developer Guide / Reference / DStore API Reference
   • 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
   • 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
   • Update Copyright Year and Release Version where necessary
   • Must not have any broken hyperlinks
   • See User doc checklist
7. 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 [Martin]
    • For instructions see Clarification on use of iplog flag
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
    • 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. 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. Clean-up Bugzilla Target Milestones
19. Produce the release review documentation [Martin]
20. 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. At Release Time: Tag the CVS and SVN Repositories with the R3_2 release identifier
    • TM: R3_2, TCF: tags/0.3.0