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.
- make clean
- check if any bundled dependency modules need updating, and if so:
- note such changes in MANIFEST
- note such changes in Makefile.PL
- edit package for VERSION
- edit NEWS for VERSION
- cvs update
- cvs commit
- update ChangeLog using cvs2cl
- perl Makefile.PL
This step checks for files not in MANIFEST.
This step creates a temporary package, and runs through the testing process.
copy newly-created package dist.tar.gz to another directory
untar the copied dist.tar.gz
ensure any bundled-modules were included in the package
make all test
test the installed program manually
if possible, ask others to test the dist you just made
go back to your code directory
cvs tag tag-name
I like to use the tag-template release-x-y-z. For example, release-0-1-5.
go back to your dist.tar.gz
gpg –detach-sign dist.tar.gz
cd incoming/ && PUT dist.tar.gz && PUT dist.tar.gz.asc
perform web-based SourceForge project file-release process
mail to announce lists