/usr/share/crawl/docs/develop/release.txt is in crawl-common 2:0.13.1-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 | 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. ;)
|