Introduction

Having botched releases is a software developer’s nightmare. One spends a lot of work designing, coding, and publicizing, only to have it so that users who download the just-released package can’t use it at all. This destroys users’ faith in the software and developer, and may not even come back to it when the problem is fixed. Even worse, often the users will not even report the problems to the author, so the developer is left in the dark as to the fact users are having problems!

I personally have horrendously botched releases; in particular, once I had to do about 4 releases in 3 days, due to a mixture of errors ranging from missing files in the package, to failure to compile. It was a mess; thankfully, I had helpful users who actually reported the problems they were having in a quick manner, so that I was able to repair my mistakes. However, since I had not yet had a developed a process to go through before releasing, I would fix the problem, but release with a different problem. It was awful, and demoralizing.

After that incident, I made up my mind to write down the steps I should take when releasing software. The steps are primarily for Perl software, since that what I primarily work on. I follow these steps religiously, not deviating from them one bit during the release process. And it has helped; since I began following these steps, I have not botched a release yet, and I’m very proud of that.

Perl release steps

Note that these steps assume you are packaging your product using the standard Perl tools such as ExtUtils::MakeMaker, and use CVS to manage your code.

If any of these test-checking steps fail, then start over at the beginning of the steps.

  1. make clean
  2. check if any bundled dependency modules need updating, and if so:
    • note such changes in MANIFEST
    • note such changes in Makefile.PL
  3. edit package for VERSION
  4. edit NEWS for VERSION
  5. cvs update
  6. cvs commit
  7. update ChangeLog using cvs2cl
  8. perl Makefile.PL
  9. make distcheck

    This step checks for files not in MANIFEST.

  10. make disttest

    This step creates a temporary package, and runs through the testing process.

  11. make dist

  12. copy newly-created package dist.tar.gz to another directory

  13. untar the copied dist.tar.gz

  14. ensure any bundled-modules were included in the package

  15. perl Makefile.PL

  16. make all test

  17. make install

  18. test the installed program manually

  19. if possible, ask others to test the dist you just made

  20. go back to your code directory

  21. cvs tag tag-name

    I like to use the tag-template release-x-y-z. For example, release-0-1-5.

  22. go back to your dist.tar.gz

  23. gpg –detach-sign dist.tar.gz

  24. ftp upload.sourceforge.net

  25. cd incoming/ && PUT dist.tar.gz && PUT dist.tar.gz.asc

  26. perform web-based SourceForge project file-release process

  27. update Freshmeat

  28. mail to announce lists