Thunderbird:Doing Releases/Writing Release Notes
<<< back to Thunderbird:Doing Releases
Contents
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).
- 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.
- Copy the previous release notes to a new directory e.g.
svn copy en-US/thunderbird/3.0a2 en-US/thunderbird3.0a3
- Add new link to the new directory/release from
en-US/thunderbird/early_releases/index.php
- 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.
- 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.
- Edit
en-US/thunderbird/early_releases/downloads.php
to provide information appropriate to the current release. - Edit
includes/thunderbirdBetaDetails.class.php
- Ensure the list of locales under var $primary_builds = array(... matches the list of shipped locales (as updated pre tagging).
- 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
- Push pages to staging
- Comment on the release notes bug and ask for people to check/comment.
- Update as comments come in & respond on the bug when the updates have been pushed.
- 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.