A big obstacle to releasing 2.0 and hitting a 6 month development cycle will be really integrating our QA process. For development releases, we don't need to put as much control over what we release and when we release things. It's prefectly acceptable to have a semi-broken development release. Once we start moving into RC and stable releases we've got to let the QA team pull the trigger for us. This means really adjusting the way that we do business. I've been thinking about how to rearrange our management structure to make this more achievable.

Philosophy My general philosophy for Koha's ongoing development is that we should maintain three release trees at any given time: Legacy, Stable, and Development. By early summer, I'd expect these to be 1.2, 2.0, and 2.2 respectively. The Legacy and Stable trees should each have their own cvs branch (rel-1-2 and rel-2-0), while the Development tree lives in the main cvs branch. Releases (snapshots) of the Development tree should be made weekly or bi-weekly. Releases of the Stable tree should be made monthly or bi-monthly. Releases of the Legacy tree should be made as needed for security.

If we can hit the 6month cycle I mentioned above, then I'd imagine that it would work like this (for versions 2.0, 2.2, and 2.4):

Now - rel_2_0 is branched, from here on out only bug fixing work is done in this tree. The stable release lead might decide to backport an improvement from the MAIN cvs tree if there is a sizable advantage and minimal risk. The MAIN cvs tree is used for ongoing development. One or more 2.0.X releases should be made.

in 2 months - rel_2_2 is branched. No new features can be added to this tree without the approval of the development leads. We spend 2 months stabalizing and polishing Koha with 2.1.X releases being made frequently. Any features/modules deemed not ready for prime time are removed from the rel_2_2 tree. Major feature addition/development proceeds in MAIN, and bug fixing proceeds in rel_2_0. One or more 2.0.X releases should be made.

in 4 months - rel_2_2 development freezes and we enter bug squashing mode. 2.2.0PreX then 2.2.0RC releases are made frequently. The stable release lead manages releases from 2.2.0RC1 on. New development continues on the MAIN tree, and bug fixing continues on the rel_2_0 tree. One or more 2.0.X releases should be made.

in 6 months - rel_2_2 becomes the stable tree with the release of 2.2.0, rel_2_0 becomes the legacy tree, and rel_1_2 is depracated. New development work continues on the MAIN tree.

in 8 months - rel_2_4 is branched. No new features can be added to this tree without the approval of the development leads. We spend 2 months stabalizing and polishing Koha with 2.3.X releases being made frequently. Any features/modules deemed not ready for prime time are removed from the rel_2_4 tree. Major feature addition/development proceeds in MAIN, and bug fixing proceeds in rel_2_2. One or more 2.2.X releases should be made.

in 10 months - rel_2_4 development freezes and we enter bug squashing mode. 2.4.0PreX then 2.4.0RC releases are made frequently. The stable release lead manages releases from 2.4.0RC1 on. New development continues on the MAIN tree, and bug fixing continues on the rel_2_2 tree. One or more 2.2.X releases should be made.

in 12 months - rel_2_4 becomes the stable tree with the release of 2.4.0, rel_2_2 becomes the legacy tree, and rel_2_0 is depracated. New development work continues on the MAIN tree (and will eventually become rel_2_6).