Over at my day job, I’ve been spending some time reworking the way users create and manage releases in rBuilder. Here’s a nice little run down on what has changed:

How It Used To Work

Beforehand, a project owner was the only one who could create a release. A release was created by choosing:

• A group trove by its name, version and flavor¹
• An “image” type (e.g. Installable ISO, Raw Filesystem Image, etc.)
• A host of image specific options (advanced options)

This was all well and good. Once a release was created, it could be downloaded and tested. If it passed muster, it could be published so the world could see it. If it didn’t, then it could be deleted, and the cycle could start over.

This was fine, except for the following issues:

• Most project owners want to lump together several images into a release. For example, release 1.0 of My Spiffy Linux might be offered for both 32- and 64-bit x86 architectures as a installable ISO as well as a 32-bit x86 raw bootable image (for QEMU, Parallels, etc.). Each one of these had to be created and published separately. Once published, they would show up as separate releases within rBuilder, even though they are logically a part of the same release as far as the project owner (and his users) are concerned.
• Once you published a release, it could never be modified. This means that you as a project owner clicked that button, that release was permanently released to the world. You couldn’t unpublish it. You couldn’t edit the release notes. You couldn’t do anything. If it was a bum release that ate peoples’ systems, you were stuck with it…forever.
• Project developers could not build or see releases. Thus, project developers could not download the release (except via a direct URL link), nor could they participate in testing the distro themselves.

Enter the “Build”

We have solved this problem by making what used to be known as a “release” a “build”. You generate builds the exact same way as you would have generated a release². Once you are satisified with a set of builds, you can collect them into a release. Releases can then be kept around and builds can be added or deleted as desired. When the release is ready to go “gold”, it can then be published.

How is this better?

I knew you’d ask. Here’s how:

• First of all, project developers can now create a build as well as see a list of builds within the current project. No more having to beg to be project owner to create a build. No more having to pass out a direct download URL to your project developers.
• Secondly, any group of builds can be created into a logical release. This means a single release can contain builds from different group-troves (i.e. a Live CD image might be created from a different group trove that is better suited for the Live CD environment than the installable ISO images withing the same release). This gives more power to the project owner to create a release as he or she sees fit. (It also means the Recent Releases list is less cluttered).
• Finally, releases can be unpublished after publishing. So you screwed up? No problem. You can always pull back a release and either modify it by adding/deleting builds, changing release notes, or even deleting the whole darn thing.

It’s worth noting that only project owners can manage releases. This makes sense, as the owners should have final say on what gets sent out to the public.

What Happened to All My Releases?

Each release that existed previous to the upgrade was changed into a build. If it was published, a published release was created with that build as the sole contents. This was done to preserve old URLs to releases that might be out in the wild (e.g. on webpages, wikis, etc.). As a project owner, you may go out and create better groupings for releases (i.e. you might want to take all of the builds for release 1.0 of Spiffy Linux and lump them into one release). This is an exercise left up to the project owner’s discretion.

IMPORTANT NOTE FOR PROJECT OWNERS: Since the release page is currently shown in descending ordered by the time the release was created, you should re-group your builds into releases starting with the oldest build as follows.

1. Unpublish and delete each migrated release that would be a part of the oldest release.
2. Create a new release, and add the unpublished builds that were freed up from step 1 into it.
3. Save and publish the newly-created build.
4. Repeat steps 1-3 with the next most recent release until you get all the way up to the present day.

Failure to follow these instructions may make your releases page a bit haphazard with respect to the order you’d like them in.

The Future

There’s lots still to be done. For one, I’m certain that the UI can be improved. Furthermore, there are plenty of opportunities to streamline the build creation process (perhaps with project-level defaults for common builds).

Feedback is welcomed and encouraged. Try it out and leave a comment!

¹ The group trove’s flavor was specified as picking either x86 or x86-64 architecture. To say that the new trove picker lets you be a bit more specific would be an understatement.

² Thanks to Tybstar for the AJAX-y trove picker.