Thunderbird:Doing Releases/Writing Release Notes

Warning: This page is obsolete

<<< back to Thunderbird:Doing Releases

These steps are aimed at whoever is doing the release notes for the release. These are currently focused on the Alpha/Beta releases, and we will probably need to do something slightly different for Final.

Repositories

Access is required to SVN to actually push the notes: davida, Standard8 and gozer have this already. If you need access, file a bug under mozilla.org:SVN account requests, ccing davida. davida will then approve.

The currently relevant svn repositories are:

• mozillamessaging.com
• libs/product-details
  • AFAIK, no-one in Mozilla Messaging has access to product details yet, it is used read-only, but important so we can re-use some of the scripts they provide.

To check out anonymously:

svn co http://svn.mozilla.org/mozillamessaging.com/sites/mozillamessaging.com/

You don't need to get libs/product-details manually, that is done for you.

Tags and Servers

• Work is done in mozillamessaging.com/trunk, commit when you want to.
• Get svnmerge from here and install it in your $PATH
• When ready to push to stage:

cd ../tags/staging
# Query what changes are available for merging
svnmerge avail
# merge all or cherrypick
svnmerge merge [ -r 1234-1237,1239,1240 ]
# Checkin the merge with a nice autogenerated log message
# svn ci -F svnmerge-commit-message.txt

• At the moment, poke gozer to get stage to update to the latest revision. This will push them onto stage.mozillamessaging.com
• Gozer is currently doing the push from staging to production, but similar steps should be used.

• Standard8 found it useful to document the changes as he went along, see Releases/Thunderbird_3.0a3:WebsiteNotes for an example.

Creating a new set of release notes etc

Do all your work in mozillamessaging.com/trunk. It can be useful if you have a local web server with php set up (Standard8 used the built-in Mac one).

1. File a bug for release notes tracking and to allow people to comment, e.g. bug 457186, cc the main folks driving the release, as well as others who may wish to comment.
2. Copy the previous release notes to a new directory e.g.

svn copy en-US/thunderbird/3.0a2 en-US/thunderbird3.0a3

1. Add new link to the new directory/release from en-US/thunderbird/early_releases/index.php
2. Update all the files under en-US/thunderbird/<release> to replace the old version with the new version. Replace dates by XXX for the time being (so that they aren't forgotten/missed).
   • Note: Beta releases will have official branding, alpha releases won't.
3. Edit release notes and other pages to include appropriate details in the release.
   • The new features section can be filled out with the help of the rumbling edge or via searches in bugzilla.
   • When doing pages such as links to downloads, also try to point the users to the release notes & known issues.
   • For the rumbling edge link (and number of bugs fixed) talk to Garry.

Updating the downloads page

The downloads page is mainly formulated from a php array to make generating the links easy.

This is probably something to integrate into the build & release process.

1. Edit en-US/thunderbird/early_releases/downloads.php to provide information appropriate to the current release.
2. Edit includes/thunderbirdBetaDetails.class.php
   1. Ensure the list of locales under var $primary_builds = array(... matches the list of shipped locales (as updated pre tagging).
   2. Update files sizes for the downloads
      • If these aren't available, they can be left until later.
      • Gozer can probably generate a list of sizes.
      • Currently these aren't used, but we will probably start using them later, so let us get used to doing them now.

Next steps

1. Push pages to staging
2. Comment on the release notes bug and ask for people to check/comment.
3. Update as comments come in & respond on the bug when the updates have been pushed.
4. Repeat.

Once the release is ready, one of the release steps is for QA to verify all the links, and then the changes can be pushed to stage.

Creating an announcement

• [1] documents this quite nicely.
• It is probably best that the announcement is committed in separate changeset and that it isn't pushed until after QA has checked the pages on the production site.
  • Hence get the pages up and tested before posting the announcement.
• Announcement can be written in background to be ready though.
  • Standard8 got davida and rebron to approve it and QA to check at release time.