Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Prepare and distribute documentation plan

The documentation plan should be ready prior to code freeze.

It should include which sections of the documentation need to be updated, and by whom.  Besides new/modified feature documentation, the following need to be updated for each release:

  • Release notes.  These should start with a 1 or 2-paragraph summary of the release, which should be sent to Carol Minton Morris (clt6 at cornell dot edu) for review several days prior to release day.  This text will be incorporated in the release announcement.
  • Upgrade/Migration guide
  • Installation/Configuration guide
  • Front page of documentation wiki (to be modified in place on release day...see "Complete wiki documentation updates" section below for details)

Prepare and distribute test plan

The test plan should also be ready prior to code freeze.

...

  • Which platform/database combinations will be tested
  • Which automated tests will be run, and by whom
  • Which manual tests will be run, and by whom
  • Which service compatibility tests (GSearch, OAIProvider, SWORD-Fedora, DirIngest) will be run, and by whom
  • Instructions on how testers will report on test results

...

For disaster recovery purposes, we keep an archive of all files we release to sourceforge.

To do this:

  1. sftp to fedorafcrelman@fedora-commons.org using the fcrelman account
  2. cd Follow the symlink at ~/ release-archive
  3. Create a subdirectory based on the release date, e.g. 2009/12-07/fedora-3.3/
  4. Upload all released files to this directory.

Complete wiki documentation updates

At this point, the completed documentation should be ready to be "swapped in" and made live in the wiki.

  • Rename the SPACE using the new version number, e.g. "Fedora Repository 3.3 Documentation".  This will ensure that the version number is visible in the header area of all pages within the documentation.
  • Update the front page of the space:
    • Rename the PAGE the same as the SPACE, e.g. "Fedora Repository 3.3 Documentation".  This will ensure that the version number is obvious and prominent in the content area of the main documentation page.  It will also cause anyone with bookmarks to the old main page to realize that the version of the current documentation has been updated.  After clicking the suggested link on the 404 page, they will see where they can access the archived documentation.
    • Update the content of the page:
      • All download links should point to the new version's files
      • The javadoc link should go the javadocs URL for the new version
      • Linkage for "Older Versions" of documentation should be updated to include a link to the documentation snapshot for the now-previous version.
  • Update the Release Notes parent page.
  • Update the License and copyright page.
  • Make any final changes to the new release notes page
  • Remove all warnings about a feature being for (this) future release of Fedora
  • Update the "Upgrade and Migration Guide" with the new content.
  • Update the "Installation and Configuration Guide" with the new content.
  • Make sure the copyright at the bottom of all doc pages is accurate.

Update high-level pages on fedora-commons.org website

...