Release Checklist

What to do at release time

At the 3.0 release it was obvious that we didn't have everything setup fine in time when the announcement was made. This is an attempt to list what we should do/have done at the time of the release announcement!

Some steps only apply if we want new flash packages to accompany the release. These are marked FLASH.

1. git pull --rebase the release branch to the correct state
2. FLASH: bump LATEST_BOOTLOADER_VERSION in apps/plugins/rockbox_flash.c and the flash package version and rockbox release version in the manual (archos-flashing.tex).
3. FLASH: build bootbox and the flash loader (flash/bootloader/) for all archoses. Test-assemble the flash packages (without a main image) and check for rombox address mismatch. On mismatch, fix it and restart from the previous step.
4. edit the build scripts (tools/release/*) to use the correct version string for all builds
5. build all the Rockbox binary zips (and fonts) (using ./tools/release/bins.pl)
6. FLASH: Assemble the flash packages using the previous images, a hex editor, the flash loaders and bootbox just built, plus rockbox.ucl/rombox.ucl from the release packages just built.
7. build the source 7z archive (using ./utils/common/tarball.py) (needs to be done after tagging)
8. build all manuals (using ./tools/release/manuals.pl)
9. build all voices (using ./tools/release/voices.pl)
10. copy zips, source, manuals and voices to the download mirror master
11. update release version in tools/builds.pm
12. tag the release (see https://www.rockbox.org/wiki/UsingGit#Tagging)
13. make sure we have a rbutil version around that can install the new version
14. make sure there's a proper release notes wiki page in order
15. update the download page to link to new current release packages / docs
16. add the release number to flyspray
17. draft a press release so that any pages covering it have some basic "correct" facts about Rockbox they can use
18. send release announcement mail to the Rockbox mailing lists
19. update the revision number in update_front.sh in the www repository used to generate since-release.html (it should be the revision number the release branch was branched from).
20. update index.t and history.t in the www repository with new release info, and update the website.
21. update release checkwps binarys on the themesite, run checkwps on all themes.
22. get an administrator to update the website and download server