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.

Average Rating: 4.5 out of 5 based on 193 user reviews.

3 Responses to “”

  1. Adrian Boeing says:

    My god. Have you ever tried premake??
    http://premake.sourceforge.net/

    Or even CMake?

    And using batch files/scripts to do the compiling and SVN work for you?
    http://adrianboeing.blogspot.com/2009/07/batch-files-and-svn.html

    This will seriously drop the time you require for making a new release to around 5 minutes, and it will mean you can release and test more often!

  2. arturh says:

    I know it is non-trivial to set up, but you could *really* use a good build server. It could automatically do all those things for you (after you invest many many many hours configuring it) so the Future: release todo list would just be:

    1. tag the new release with new version number in svn
    2. wait …
    3. distribute the packages build by the buildserver

  3. Simon Schmei├čer says:

    I second on CMake and maybe trow in CTest for automated testing and Cpack for creating the packages.

    It’ll give you project files for about every IDE and best is, you don’t have to ship them, because each user can easily build them himself. (“cmake . -G YourIDE”)

Leave a Reply