New release model for Horde 4

We started development on Horde 4 almost 3 years ago, and we could probably work another 3 years and still would find things to do and to improve. So we decided to make a cut now and get Horde 4 out of the door. The lessons learned during development also lead to a different release model for Horde in the future.

Release models

There are basically two different release models in the Open Source world. Releasing when you are done, and following a fixed release timeline. In the first model, you decide which features you want to have in a release, and then start working on those until you are done. This is what we did in Horde so far. This model works especially well in projects that are completely volunteer-driven and happen mostly in the developers' free time. The project members are doing this for fun. If anybody else could make any use of the code, it's fine. If not, that's fine too.

But when a project's focus starts shifting towards a more professional approach this doesn't work well anymore in most cases. Such a shift could be caused by internal reasons, for example because members of the project start to make a living of the software, or by external reasons, because the software is increasingly used in business environments. In the Horde project both happened at the same time, already quite some time ago.

Because of that and because we started to get frustrated that Horde 4 development didn't come to an end, we decided to make a cut. We picked a few really important road blocks that we felt had to be included in the next release, dropped everything else from the original release goals, and set a fixed release date. Horde 4 will be released on 5th of April 2011.

But we don't want to stop here. With the lessons learned from more than 10 years of OSS project management, and with the urge to give the project a fresh spin, we decided to change the release model to a fixed release timeline for future releases too. A difficult part of the discussion about this new release model was to find a good balance between allowing to break backward compatibility to not hinder development, and providing and supporting a stable API for 3rd-party and in-house developers.

New release model for Horde

These are the key points that have been decided, some new, some continuing our "old" rules:

*APIs in this context mean PHP APIs of framework components, external PHP APIs of applications, and external Horde RPC APIs.

Branch management

As a consequence of these discussions, we will actively maintain 3 development branches:

If for example we already had 4.0, 5.0 and 5.1 releases and are now working on the 6.0 release, we would maintain FRAMEWORK_4_0, FRAMEWORK_5_1 and master branches. Once 6.0 is released, we maintain FRAMEWORK_5_1, FRAMEWORK_6_0 and master branches.

Security support

This means that major versions will be maintained with security fixes for at least 12 months, in reality even longer, because we don't expect to break BC and thus require new major versions with each half-year release.