Making RakNet releases, then vs. now

Then:

1. Rebuild all
2. Run a batch file to delete temporary files (.obj, etc.)
3. Zip the whole directory
4. Add a comment to revisionlog.txt
5. Upload it, overwriting the old file (RakNet.zip)
6. Change the date on the front page
7. If I remember, also change the version number in readme.txt

It took me about 5 minutes to make a build. As a result, anytime I found a bug I’d basically release a build immediately.

Now:

1. Rebuild all
2. Of the over 50 projects, fix the ones that no longer build
3. Fix warnings introduced by various ifdefs
4. Build on Code Blocks, adding new files. Fix compile errors/warnings.
5. Build on Dev-cpp, adding new files.
6. Go to the source directory, do dir *.h, copy out file list to a text editor. Modify output to match formatting tags for makefiles. Copy output to makefile.
7. Do the same for *.cpp
8. Do a similar process for the VC6 project (if I bother)
9. Build in Visual Studio again to make sure things still build
10. Copy source files to CYGWIN. Figure out how to compile in GCC again, and fix any compile errors if any.
11. Run through the easier to test projects to make sure the major features still superficially work
12. Figure out when the last build was made, look up the log from SVN, and collect all the check-in log entries
13. Format the log entries and add them to revisionlog.html. This is non-trivial, to prevent revisionlog from being unreadable
14. Change the version number in readme.txt and RakNetVersion.h
15. Update the remote dedicated server from SVN, rebuild, and restart
16. Generate the Irrlicht demo exe. Download the .zip from the website, update the exe, and reupload
17. In SVN, create a tag with the version number, which involves looking up how to do it each time
18. Regenerate the Doxygen html documentation
19. Run HTML help workshop to generate the chm documentation. Move the chm file out of the html file.
20. If I remember, upload the new Doxygen documentation to the website
21. Export from SVN to a temp directory.
22. Zip the files in the temp directory. Sometimes there are unusual steps here, such as unzipping the ogre sample (lately I don’t bother to do that).
23. Upload the zip to Sourceforge
24. Figure out how to navigate the Sourceforge interface to get to the new releases page (which takes me a couple of minutes every time)
25. Add a new release. Paste in the revision log from earlier. Add the file, and submit.
26. Upload the same zip file to the website, making sure the version number of the filename of the zip file is correct.
27. Open the 6 different pages on the website that reference the link and update them.
28. Update the news page in the forum to point to the correct link
29. Add a post to version announcements with the revision log.
30. I used to also edit the download graphic with the correct version number. But this got to be such a pain I just changed it to 3.x so I wouldn’t have to keep modifying it.
31. Sometimes send a post to gamedev.net about the new release (lately I don’t usually bother).
32. Think about which of these steps I forgot, and sometimes redo part of this if I did.

It takes about an hour to make a build. I do a build every 1-3 months, depending on if I find any major bugs and how stable I feel the code is. If I’m changing existing code every day I usually won’t release.