CVS-based Software Release Steps

Posted 16 Mar 2001 at 01:34 UTC by jtauber Share This

For my main project on SourceForge, Redfoot, I've developed a set of steps to follow to do a release. I've started using them on all my CVS-based projects. I'd be interested in getting feedback on the steps and what steps others follow.

  • do a clean checkout of foo from CVS with -P
  • make sure CHANGELOG is up-to-date (hopefully has been done continuously)
  • tag the release
    • cvs tag RELEASE_X_XX_XX
  • up CVS major revision (so 2.0 = first release, 3.0 = second release, etc)
    • cvs commit -m "NEW RELEASE" -r y.0
    • cvs update -A
  • rename directory to foo-X.X.X
  • tar
    • tar --exclude=CVS cvzf foo-X.X.X.tgz foo-X.X.X
  • release on sourceforge (or whereever hosted)
  • send freshmeat announcement
  • announce elsewhere (relevant mailing lists, news groups, etc)

cvs2cl, posted 16 Mar 2001 at 02:23 UTC by ftobin » (Journeyer)

Instead of writing your own ChangeLog, I highly recommend using cvs2cl, a tool which writes out a ChangeLog based from CVS comments. Using cvs2cl takes the work of maintaining the ChangeLog from humans, and allows it to be auto-generated at shipping time. Your ChangeLog will be much more useful now, as it does two things:

  1. Encourages you to write useful CVS commit comments.
  2. Relies on previously-generated writings about what has happened in the code. Less work duplication this way.

Perl, CVS, SourceForge release steps for me, posted 16 Mar 2001 at 02:38 UTC by ftobin » (Journeyer)

I wish I had access to my main box right now, because I have written down on it the sequence of steps I go through when release Perl based software using CVS. The sequence, if I remember correctly, goes like this:

  1. cvs commit
  2. cvs update
  3. update NEWS
  4. cvs2cl
  5. make clean
  6. perl Makefile.PL
  7. make all test
  8. make clean
  9. perl Makefile.PL
  10. make dist
  11. cp project.tar.gz /another/dir
  12. cd /another/dir && tar -zxvf project.tar.gz
  13. perl Makefile.PL
  14. make all test
  15. cd /original/dir
  16. cvs tag release-number
  17. gpg --detach-sign project.tar.gz
  18. scp project.tar.gz.sig
  19. ftp and put file in incoming dir
  20. perform web-based SourceForge release

All of this assumes I have test scripts, and my ~/.cvsrc contains something like:

update -PAd

As you can see, I am very thorough in my releases, making sure I don't release something that goes BOOM in the users' face (I had this happen twice before I got this procedure down). In my experience, it is extremely important to have a comprehensive series of steps to go through before something is released.

automake, posted 16 Mar 2001 at 07:19 UTC by bagder » (Master)

Since no one said it yet:

'make distcheck'

Builds a release archive, unpacks it in a new directory, runs configure and builds everything and then runs the test suite. Then it deletes the generated stuff again leaving only a tarball and a result that hopefully says "package ok to release". All this fully automatically.

If you use automake.

When this works, I update the version number, commit all changes, tags all sources with the version number and release it. The Changelog is already and always kept up-to-date as it is reflected on the web site (and CVS of course) and people don't want to wait until official releases until they can read what's been going on.

Basing version number on CVS changes., posted 16 Mar 2001 at 12:47 UTC by davidw » (Master)

I created a small script, cvsversion.tcl, which checks to see if any files have changed in CVS, and if they have, asks you if you want to update the major, minor, or point number of the software.

disttest, posted 16 Mar 2001 at 19:10 UTC by ftobin » (Journeyer)

Since bagder's suggestion of "distcheck", I looked into Perl's ExtUtils::MakeMaker support, and found another useful command, "disttest". Basically, it does automatically what I manually listed in my previous comment, namely:

  1. creates a distribution directory
  2. runs "perl Makefile.PL"
  3. make
  4. make test

This will certainly shorten some of my steps!

Whatever you do, HAVE those steps in WRITING, posted 17 Mar 2001 at 07:21 UTC by jhermann » (Master)

My release steps are on bin/moin/moin/MoinMoinRelease and of course only differ in details from the others. The important thing is to have such a cookbook recipe, so no step is forgotten. There is a tendency in many OS projects to avoid anything that reeks remotely of project management, but if other people rely on your work, it cannot be avoided.

cvs export, posted 18 Mar 2001 at 07:40 UTC by moshez » (Master)

I *never* release from my working directory. I "cvs tag v$major_$minor_$patch", and then I "cvs export -r" from another directory. This makes everything much safer.

I even have a "release" script, which given major/minor/patch argument cvs exports, builds the debian package (which also builds the orig.tar.gz tarball), and lintian checks it.

updated list of steps, posted 18 Mar 2001 at 08:26 UTC by jtauber » (Master)

I definitely should be doing an export. So the list of steps would look something like this...

  • update CHANGELOG (perhaps automatically)
  • tag the release
    • cvs tag RELEASE_X_XX_XX
  • up CVS major revision (so 2.0 = first release, 3.0 = second release, etc)
    • cvs commit -m "NEW RELEASE" -r y.0
    • cvs update -A
  • export to a new directory
    • cd ..; cvs export -r y.0 foo-X.X.X foo
  • tar
    • tar cvzf foo-X.X.X.tgz foo-X.X.X
  • release on sourceforge (or whereever hosted)
  • send freshmeat announcement
  • announce elsewhere (relevant mailing lists, news groups, etc)

whoops, got export line wrong, posted 18 Mar 2001 at 08:30 UTC by jtauber » (Master)

should be

  • cd ..; cvs export -r HEAD -d foo-X.X.X foo

test before you release, posted 19 Mar 2001 at 22:34 UTC by jrobbins » (Master)

One big area no one has mentioned is testing. You should never release software without doing acceptance testing. In general, I feel like the open source community has forgotten testing altogether.

As part of the 'make release' script, one should run 'make test'. And, of course, that implies that you should have some working test scripts before you imagine your stuff to be a release candidate in the first place.

releasing..., posted 28 Mar 2001 at 21:00 UTC by xtifr » (Journeyer)

jtauber: thank you for mentioning cvs export!! This is something that far too many people seem to be completely ignorant of! Please, everyone, learn about cvs export, and USE IT! Your tarballs will be cleaner, and people like me who often maintain local cvs repositories will stop cursing your name every time a new release comes out! Yes, it is possible to work around the need for cvs export, but why bother? Why not use the tool the way it was intended to be used, and lower the chance of overlooking some important detail. (I am particularly angry at the many gnome developers who seem to think that cvs export is an evil command, to be avoided at all costs.)

jrobbins: testing is important, no doubt. However, many people seem to get angry if you "waste time" testing. It violates (in their tiny minds) the principle of release-early-release-often. Sad, isn't it?

Automate it, posted 5 Apr 2001 at 15:45 UTC by exa » (Master)

Roll these steps in a make target if possible and it should be more straightforward to apply. Personally, I only tag the tree and export it, but having a working test suite is a most necessary element of development so it is more than important to do a 'make check' before release.

I'd like to write a 'make cvsdist' that does these in my automake (hopefully) replacement.


New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page