Then:
- Rebuild all
- Run a batch file to delete temporary files (.obj, etc.)
- Zip the whole directory
- Add a comment to revisionlog.txt
- Upload it, overwriting the old file (RakNet.zip)
- Change the date on the front page
- 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:
- Rebuild all
- Of the over 50 projects, fix the ones that no longer build
- Fix warnings introduced by various ifdefs
- Build on Code Blocks, adding new files. Fix compile errors/warnings.
- Build on Dev-cpp, adding new files.
- 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.
- Do the same for *.cpp
- Do a similar process for the VC6 project (if I bother)
- Build in Visual Studio again to make sure things still build
- Copy source files to CYGWIN. Figure out how to compile in GCC again, and fix any compile errors if any.
- Run through the easier to test projects to make sure the major features still superficially work
- Figure out when the last build was made, look up the log from SVN, and collect all the check-in log entries
- Format the log entries and add them to revisionlog.html. This is non-trivial, to prevent revisionlog from being unreadable
- Change the version number in readme.txt and RakNetVersion.h
- Update the remote dedicated server from SVN, rebuild, and restart
- Generate the Irrlicht demo exe. Download the .zip from the website, update the exe, and reupload
- In SVN, create a tag with the version number, which involves looking up how to do it each time
- Regenerate the Doxygen html documentation
- Run HTML help workshop to generate the chm documentation. Move the chm file out of the html file.
- If I remember, upload the new Doxygen documentation to the website
- Export from SVN to a temp directory.
- 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).
- Upload the zip to Sourceforge
- Figure out how to navigate the Sourceforge interface to get to the new releases page (which takes me a couple of minutes every time)
- Add a new release. Paste in the revision log from earlier. Add the file, and submit.
- Upload the same zip file to the website, making sure the version number of the filename of the zip file is correct.
- Open the 6 different pages on the website that reference the link and update them.
- Update the news page in the forum to point to the correct link
- Add a post to version announcements with the revision log.
- 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.
- Sometimes send a post to gamedev.net about the new release (lately I don’t usually bother).
- 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.