Announce final list of features

In order to bring everyone up to date with which features the next milestone should be equiped a final list of features is created and written in stone. This list should not be changed until the release cycle is completed. We all know how frustrating is can be to try and hit a moving target. This step should nail the target down ;). This list is usually announced through the jcast-hackers mailinglist.

Code Freeze

After everyone knows what features are to be included in the next milestone a "code freeze" is announced through the mailinglist. During code freeze changes to JCast-X sourcecode will more and more seldom. Until the CVS is frozen and no one sees the need for further changes.

Create CVS branch

The frozen cube of sourcecode is taken into its own branch inside CVS. This step enables the "hot" developers to finally submit their on-the-edge-code to the MAIN CVS branch ( continue development ). Plus it also enables the "other" developers to continue with the next steps of the release cycle at the same time. This minizes the time-loss of real development inside the CVS which is caused by a release, and maximises the code quality by effectivly splitting the source-base. Once the branch is created inside the CVS, further work for this milestone is only done within the branch.

Install tests, Runtime tests

The most important steps during a release are to ensure the when people finally start downloading the new release it installs and to make sure it runs more than just for 5 minutes! In order to achieve that tests should be done on as many different platforms / machines as possible. I know that this is closely connected to the hardware available to the developers. In the end the release will have a readme file that shows which platforms have been tested. If bugs or other flaws are perceived during testing they are fixed within the branch. These bug-fixes are either merged with the MAIN brach, or other sollutions will find their way into the CVS. The most important thing with these bugs is that THEY ARE PUT INTO THE BUG-TRACKER. Even if the bug is fixed right away, I can not emphazise the importance of gathering bug-informations enough. YOU ALWAYS WRITE A BUG REPORT, EVEN FOR THE ALREADY FIXED BUGS!

Create SourceForge file-release

Once the package has been tested its presented to the public through the SourceForge file-release tool. That's the easy part ;).

Accept Bugs / Feature Request for released version

After the release is publicly available a new group needs to be added to the Bug-Tracker which names the new release version. This should help determine wether a bug has already been fixed, is re-appearing etc. Additionally people will request features to be included in JCast-X these requests are CC'd into the jcast-hackers mailinglist. When a bug or a requested feature would result into a change to the JCast-X sourcecode a new Change-Request has to be submitted inside the Change-Management Tracker. (See development process for details)