Steps to a Successful Release ----------------------------- The following is a step-by-step guide for how to preceed through the releasing process. For minor releases (0.X.y), steps 0 and 1 have already been done, so for those the list begins with step 3. 0. Delay branching until all features are there It makes little sense to cherry-pick actual features, or even a major amount of bug fixes. If there are features not meant for the release, please put them on a new branch. In git, branching and merging is cheap. 1. Branch master into the new version git branch stone_soup.0.X git push origin stone_soup.0.X 2. Tag the branch point git tag -s 0.X-b1 git push origin 0.X-b1 Also, after the next diverging commit, tag the trunk as 0.${X+1}-a0; you need to make sure the commits pointed to by 0.X-b1 and 0.${X+1}-a0 are different. 3. Wait and fix some bugs Wait at least 2-3 weeks for bug reports, and fix all severe old ones. When fixing bugs concentrate on the important ones (crashes and gamebreakers), but you might also want to handle the trivial ones for extra polishing. Do not EVER add any last minute features unless they can't possibly introduce new bugs. Reread the entire documentation to make sure it's up to date. Also update the change log! To check for candidates for cherry-picking: (on master) git cherry -v origin/stone_soup.0.X To actually take them: (on stone_soup.0.X) git cherry-pick -x 0123456789abc 4. Sanity testing Build the binaries (preferably on all platforms) to see if the code compiles correctly, then run some basic sanity tests including at least the following: * start a new game (both prechosen and random) * saving/loading * if there were changes that can affect saves, load a save from a previous minor version * being killed * level creation for all branches/portal vaults (using &~, &L) * accessing all help screens (including the ? submenus) 5. Sync the documentation Update the release date in the changelog. In major releases (not point ones!), use "make rest" to fetch the the manual from the wiki (https://crawl.develz.org/wiki/doku.php?id=dcss:manual:rest). Remember that after the release the wiki refers to the next major version, so any further changes need to be done in the git tree directly. Commit. 6. Tag the release In the branch you're about to tag: git tag -s 0.X.y Don't push the tag yet so you can make final amendments. 7. Package the source tarball, produce final builds "make package-source" will create three source tar/zipballs. For binary builds, you need to ensure at least the dat/ subdir contains no foreign files (such as editor backup files, uncommitted stuff, random junk, etc). Thus, "git clean -dfx". This is a potentially destructive operation so if you have files lying around, you may want to do this from a separate clone instead. Release is when you may go wild with optimizations -- the binaries will be compiled once, used by thousands of users! You want for example to specify LTO=y. If you want to bother with profile-guided stuff, this is the time. The makefile targets are "package-windows" and "package-windows-zips" for the installer and stand-alone zips respectively. Unless you're on msys, you need to specify CROSSHOST as well: make LTO=y CROSSHOST=i686-w64-mingw32 package-windows Some final testing never hurts; we're supposed to support win2k so test there as well. You need at the very least to test old Windows, new Windows, installer and zipped, tiles and console. A mandatory test is: start a new game, kill a monster, save, load, die. The in-game manual and/or FAQ are worth checking, too. 8. Push the tag Until the moment you push it to the official repository, you can delete it and re-tag. git push --tags The tags are some sort of frozen state of the source for all releases, so this is the last step you take before the actual release. All further changes make it into the next minor version. 9. Upload the files to Sourceforge Requires SF permissions for file releases. FTP/rsync access is no more, you need to use the web interface. It is pretty flaky and tends to break, often failing with specific browsers. Finally, mark it as the default download (.tar.xz source for most, .exe installer for Windows). 10. Update the homepage Modify the Downloads page over at http://crawl.develz.org/wordpress/downloads/ as necessary. 11. Announce the release Post a release announcement to the CDO blog, rec.games.roguelike.misc and rec.games.roguelike.announce. Also send an email over crawl-ref-discuss. If you want you can also write a news item on Sourceforge. 12. Lean back and enjoy the excitement -- until the first bug reports roll in. ;)