4.5. Releases

One of the important rules of open development is to "release often and release early". This ensure that developers and contributing users are up to date with the latest features and bugs. When I took control of Umbrello there had only been one unofficial release (made by me) in almost a year. My first task was to package and release the current code in CVS as a beta version. Since then I have tried to make releases more frequent than once a month.

I also set up a script, run nightly, which checks out the latest sources from CVS and packages it as a source release. This is available from the website along with the official releases. Unlike an official release, a nightly build has no guarantee of not including major bugs or even compiling at all.

Binary packages are made of official releases so most users will not have to compile the programme themselves. One of the problems with Unix-like operating systems is the enormous number of (often just slightly) incompatible configurations. I make packages for the configurations I have access to but other packages are contributed by users and developers. Requesting packages is one way to gently introduce people into contributing to Umbrello.

The releases are numbered to indicate their stability. The first release after I took over was 1.1-beta1. After another beta I made 1.1-rc1, a release candidate. The theory of a release candidate is that it will becomes the final release without any changes, although in practice this rarely happens. Finally 1.1 was released In January 2003. The larger number of users that the promise of a stable release brought to the code meant a number of bugs were found, including one which prevented diagrams from being printed. I considered this serious enough to quickly create a bug-fix release numbered 1.1.1. The current code in KDE's CVS is numbered 1.2-alpha to indicate that it has too many bugs to be of real world use.