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
120
121
122
123
124
|
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 2.
0. Delay branching as long as possible
Try to delay additions that forseeably won't make it into the next version
until the release is not too far off. Once master has been branched, you
have to commit all important changes twice, and it's easy to forget one
of them.
At the same time if something big does get introduced it's better to branch
before doing so seeing how otherwise you'll have to later turn it off in
branch before the release.
Thus, you'll need to branch as early as necessary and as late as possible.
1. Branch master into the new version
git push origin origin:refs/heads/stone_soup.0.X
2. Update version information
version.h: Set VER_NUM = 0.X, VER_QUAL = empty.
Undefine DISPLAY_BUILD_REVISION (not needed for official distributions).
3. Modify branch as needed
Turn off all features that are not balanced or finished enough to make it
into the release. This can be a bit of a hassle, so do try to avoid this in
the first place. (See 0.)
4. Wait and fix some bugs
Wait at least a week for some last minute bug reports. When fixing bugs
concentrate on the important ones (crashes and gamebreakers), but you
might also want to handle the trivial ones for extra polishing.
If you add any last minute feature or bug fixes doublecheck everything,
so you don't accidentally introduce new bugs, and wait at least another
day for potential bug reports to roll in.
Reread the entire documentation to make sure it's up to date.
Also update the change log!
5. 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 (including loading from previous minor version)
* being killed
* level creation for all branches/portal vaults (using &~, &L)
* accessing all help screens (including the ? submenus)
If you want to be thorough, play a tutorial for each of the three character
builds. This way, you get to test melee, spellcasting, and ranged combat,
and at the same time you can check that the information handed out during
the tutorial is up to date.
6. Package the source tarball and zip
On Linux, run "make package-source" in the source tree to create the source
tarball and zip. Extract the resulting packages into different folders,
compile their source and run the basic sanity tests. Also check whether
the doc, settings and dat subfolders contain all relevant files.
7. Tag the release
In the branch you're about to tag:
git tag -a release-0.X.y
You'll need to push the tag into repository:
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 either make it into the next (minor) version, or, if they are
important bug fixes and happen before the release took place, have to be
merged into trunk AND branch AND the corresponding tag.
8. Checkout the release tag
git checkout -b stone_soup-0.X release-0.X.y
You may want to make a new shallow clone into a new folder, to make sure you don't get any compilation stuff into the distribution.
Package the source (as described in 6.) and build the binaries. If you want
you can do some more sanity testing but it shouldn't be necessary anymore.
9. Upload the files to Sourceforge
Probably requires SF permissions for file releases.
You could use for example rsync (on Linux) or FTP.
See https://sourceforge.net/apps/trac/sourceforge/wiki/File%20management%20service
for reference. Compare the file sizes to make sure the upload went
correctly.
If using rsync, the correct command is:
rsync -avP -e ssh FILENAME USERNAME,crawl-ref@frs.sourceforge.net:/home/frs/project/c/cr/crawl-ref/
10. Create a new release in Sourceforge's file release system
Requires SF permissions for file releases.
* Click on Project Admin -> File Manager
* Create a new folder under "Stone Soup" named by version number -> 0.X.y
* Right-click on the uploaded files to Cut and later Paste them into the
newly created folder.
* Click on a file to change its settings.
* Mark a file as default for a given platform, so the "Download Now" link
can refer the user to the most fitting file for their system.
You can use an older release as a guideline (but don't actually modify it!)
See https://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download
for some more detailed explanations.
11. Update the homepage
ssh -t username,crawl-ref@web.sourceforge.net create
Go to /home/groups/c/cr/crawl-ref/htdocs.
Paste the changelog into a newly created 0.X.txt
Modify index.html to update the version number (the link will always point
to the most recent release) and add a new news item. For the latter, use
<a href="0.X.txt">text</a> as a link to the change log.
12. Announce the release
Post a release announcement to 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.
13. Lean back and enjoy the excitement
-- until the first bug reports roll in. ;)
|
