I'm still undecided about how to handle compiling from source with the injector. There are two models I'm considering:

• Each binary interface has a corresponding source interface. Executing a source interface creates a binary package, which can then be added to the binary interface's list of implementations.
• Source is another type of architecture (probably a low-priority one). So, the injector will pick a binary archive for your platform if one exists, or a source archive if one doesn't. Executing a source implementation still runs it, but it just takes longer the first time (sorry, can't remember who suggested this method).

I've added a 'Testers wanted' block to the news, software and developer pages. This shows all programs whose Current testing version field isn't empty. It should also remind people to mark their programs as stable after a while, instead of forgetting about it until the next release (as I usually do).

I've also created a new page type for release announcements (using Drupal's flexinode module) and added a little PHP to put an announce this release link at the bottom of each software page which will fill in some of the fields for you. The release process has been updated (and split into smaller pages).

I've been using subversion (a CVS replacement) to manage the zero-install software ever since SF.net announced they'd be supporting it in the new year (this was in 2004, I think ;-). It's been working well, except that it was on my local machine so no-one else could access it.

SF.net have finally deployed a beta subversion service to certain projects, including zero-install, and they've imported my local repository. You can check out the latest by following the instructions.

You should be able to get the whole thing like this:

$ svn co https://svn.sourceforge.net/svnroot/zero-install/trunk zero-install

It would be good to get the ROX-Filer manual imported into the new site properly:

• Pages would show up in searches.
• We could provide sensible nagivation (not just one big page).
• It would fit in with the style of the rest of the site.
• People could comment on pages.

However, I don't want two copies being edited individually. We need to be able to generate the filer's manual from the web-site copy.

The problem is that Drupal doesn't have an import filter for DocBook (the format used for the manual). Converting to HTML is easy, but that loses the markup and if we do that we can't go back (Drupal's export can't regenerate tags such as 'filename', although it can cope with chapters, I presume).

The new website is nearly ready, but there's one big decision left to make... what shall we call it?

Having 'drupal' in the URLs is a bit silly, as all the URLs will break if we later move to something else (already made that mistake with phpwiki ;-)

Moving it to the top-level could work (e.g. rox.sourceforge.net/ROX-Filer), but there's quite a lot of junk there already which we probably don't want to move in case people are linking to it (we still had rox_filer.php3 linking to the newer rox_filer.html, which redirects to the even-newer phpwiki, which will shortly redirect to drupal... we've been very good at keeping old links valid so far!)

I still sometimes see people complain that something is "only available through Zero Install". The thing is, the packages downloaded by AddApp work just fine on their own. An 'interface file' is just a list of links to tarballs (much like a web page, but machine readable rather than HTML).

But why not make the feeds human readable too? Add some XSLT and they can be! Load this in your browser:

• Sample feed

It looks like a normal HTML page, but if you do View Page Source in your browser, you'll see that it's actually an injector feed file.

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.