OSS Watch team blog

My experience with software projects so far has mainly been within the corporate sector. The projects I have been worked on involved a designer who wrote a functional design document in close collaboration with the customer, developers writing the software and software testers who did the QA and basically tested whether the software matched the design and worked without (major) bugs. The developers worked test-driven, whereas the software testers focuses on functional, end-user tests following the functional design.
Release management in these types of projects usually means that there are frequent releases, and the testers are testing release x while the developers are working on release x+1. When a critical bug is discovered, meaning one that makes it impossible for the testers to continue their work, a patch release x_01 is created in a branch. All non-critical bugs are scheduled for release x+1 to x+n based on priority, impact, and so on.

Now that I get more involved with open source projects, I experience in more detail some important differences as far as release management is concerned. When you are in a distributed open source software project, there are different ‘customers’ that each have their own set of use cases, quite possibly their own software developers implementing those, and few (if any) software testers. This makes performing QA and release management a challenge. How do you decide when a release can be created, what the scope will be and how will it be approved? Who will make sure a release is of a reasonable quality for all customers involved? Usually, with a distributed project comes distributed QA. Each customer will have to test for their own purposes, which makes it harder to coordinate a release. I would like to discuss two ways of organising the release process here.

Use release candidates

One possible approach is to use release candidates. For instance, if you plan to release version 1.2.0, you first create a release candidate 1.2.0-rc1. This release candidate is made publicly available on the website, announced on the mailing list and each developer is encouraged to test the release candidate in their own environment. In fact everyone involved is encouraged to test the release candidate in as many environments and with as many use cases as possible. A fixed period is designated for testing and critical bugs found are reported on the issue tracker and when there is consensus that this bug has to be fixed in the release a new release candidate is created in a seperate branch of the code, which will be labeled 1.2.0-rc2 and the process starts again. When there are no more critical bugs found within the test period, the release itself is created. This is exactly the same release as the last release candidate, but with the postfix of -rcx removed. Alternatively, the postfix -rc can be replaced with -ga, which means ‘general availability’.

Release without release candidates

In smaller projects where there aren’t many different user groups or developers you may consider not to use the overhead of the release candidates, but just go ahead and create the release. In our example you would rightaway create and publish release 1.2.0. But also in this case it makes sense to incorporate a fixed period of testing the release, to make sure the release is of reasonable quality. You don’t just want to dump the files out there, but would like to be sure that all the users with their different use cases have a release that works for them. A fixed testing period can help you in that process. If a critical bug is found that needs to be patched, you will have to publish a patch release, in our example that could be 1.2.0_01.
Whatever process you choose, be sure to always tag the release properly in your version control system. That way you can always create patches for the release, while continuing development on the main branch.

Release management revision

Whatever release management process you choose, the dynamic nature of many projects makes it valuable to adjust the process to your needs and for instance choose a mix of the two discussed methods. Your project may not require release candidates in general, but perhaps it makes sense to use release candidates for large releases. In any case, it is generally a good idea to revise your release process once in a while. Like methodologies such as Scrum teach us, evaluating the process is a valuable thing and this is certainly the case with release management in open source projects. Just make sure you have a good process in place for deciding on these issues and follow these processes carefully.