« previous 1 2

Proponents of rigid time based releases point to a number of positives to the approach. For example, the project can maintain momentum because there is always going to be a next release, so developers can commit changes to the code with confidence that they will appear in an official release. This in turn, some suggest, reduces the likelihood of the project forking; a number of projects have forked in the past, as a way of short circuiting the project release criteria, because some developers got tired of waiting for an official release. These things, are somewhat specific to open source projects; a proprietary project doesn't tend to deal with the possibility of external developer code being committed to it and there's usually no chance the project will fork.

Another benefit is that consumers of the project, be they users or distribution packagers, can know in advance when there will be a new release that they can use or integrate. This makes planning ahead much easier. A regular release date also means that smaller bug fixes should get included more smoothly.

There are practical problems though with time based releases. Different schedules can clash, creating very short pipelines between one project releasing and that release being incorporated in, say, a Linux distribution. Consider for example that Ubuntu 8.04 shipped with problematic audio support, forcing a re-release as 8.04.1 shortly after. Another problem is that features that require other projects to re-engineer how they work can get incorporated, without those other projects catching up. An example of this is the change in how Gnome manages sessions. The Gnome developers did the right thing and developed a replacement for the XSMP protocol, but then they switched to it in the Gnome stable build, resulting in the unfortunate situation that a number of applications not written or patched to expect it, cannot cope with the replacement. This has made its way into a number of Linux distributions, leading to complaints that now session management is broken. The final problem is that because developers are focussing on the fixed release date for new features, smaller bugs can be left behind in the wake of those features.

There will be no perfect release system. There will never be perfect software and leaving releases till the code has closely approached a state of perfection, eliminates the possibility of good enough releases. Timed releases though are based on producing good enough releases, and when they fail to be good enough, the users of that release are faced with actual show stoppers.

There has to be a middle way; a time based schedule for releases, which then turns to testing and quality assurance to ensure that as many issues as possible are fixed in the release. Think of it as a "time-out" for the project to sit on the naughty step, so a project that releases on a six monthly basis, but still has issues can, as part of the process, be allowed a further month to stabilise that release. Dependent projects can plan to use the post-time-out release date with greater confidence, and adjust their release plans, with their own space for a time-out.

"Release early and often" is a much repeated mantra of the open source community, to which should be added "to other developers". As the Linux community expands, "Release reliable code regularly for everyone else" should be the next line.

« previous 1 2