Thoughts on the release process

Frequent software releases are a problem for ROX. The biggest problem is motivation: the person in the best position to make a release is the program's main author. But why would I want to make a release of my own software? I already have the latest version!

Originally, ROX programs (like ROX-Filer) followed the Linux release system of having separate stable and developer branches. So, 1.0.0 was a stable release, then 1.1.0, 1.1.1, 1.1.2 were developer versions. Then, eventually, 1.2.0 would be the next stable release. Theoretically, this should allow you to have one very stable version for normal users.

It didn't work. The first problem is simply that stable releases are now even less frequent (once every year or two).
There's also the problem that you have to be really careful to make sure that the stable release is well tested. That means doing several pre-releases (a couple of weeks each) during which no development takes place. You can branch, of course, but then you have to remember to port all the fixes back onto the main trunk. Also, the developers get excited about adding new features and forget they were trying to make a stable release.

The second is that the developer version was almost always more stable than the 'stable' one. Almost every 'bug' in ROX-Filer is due to people upgrading one of the libraries it uses (usually GTK, because that's the biggest). Sometimes it's a new bug in the library that we need to work around. Sometimes it's a bug in ROX-Filer that is only seen with the new library.

The new system, which has been working rather well, is that every new release is a testing release at first. After a week or so without serious problems, it's marked as stable. This avoids 'brown-paper-bag' releases, because every stable release has spent time as a testing release. There are no changes to the package itself when it is declared stable; the information about whether a release is stable is kept outside the package itself (on the web page and in the injector feeds). Even the version number stays the same (ROX-Filer 2.4.1 is currently 'testing'; soon, ROX-Filer 2.4.1 will be 'stable').

This helps a lot: every developer release becomes a stable release, so stable releases are as frequent as developer ones (except for the odd reject that fails testing), and all stable releases are well tested.

But even developer releases don't happen that often. This is why I'm trying to encourage release managers. Release mangers do some of the work (writing release notes and sending announcement emails to the lists, etc). This seems to work better than the previous system. As well as spreading the work a bit, it's more motivational to be working with people (as opposed to just having people complain at you from the side-lines ;-).

The ROX release process is still quite complex, and requires coordination between authors, release managers, users, testers and translators. Worse, it needs to be spread over a period of a couple of weeks (a period for getting all the features, translations and bug-fixes in, then the testing releases, then a period to let people test that, then remembering to mark the release stable).

The effect of all this is that we get a new stable release every few months. Ideally, more of this needs to be automated. The process needs to be scripted (and the same for all programs). There should be one button to press to start it all going. There should be some way to push the release notes to the list, the news page, the file releases page, the newsgroups, freshmeat and gnomefiles all in one go, without having to enter the same information about download locations and web pages over and over again.

There also needs to be some kind of reminder that warns you when something has been 'testing' for too long. Maybe I can get something to scan my injector interface cache and send the warnings as an RSS feed to liferea? Anyone got a script for something like this? (for bonus points, extract upcoming birthdays from Contacts at the same time!).