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:
- We will stick to semantic versioning, this means:
- APIs* keep backward compatible within the same major versions. If we have to break backward compatibility, Horde 4 becomes Horde 5 etc.
- Adding features or extending APIs will bump the minor version, Horde 4.0 becomes Horde 4.1 etc.
- New versions will be released every half a year. Whether these are going to be major or minor version releases (or even just bug fix releases) depends on whether the changes since the last release broke BC or not.
- Exceptional intermediate releases can be be done for security fixes or important bug fixes.
- This only affects the Horde applications. Framework component updates will be released more often, as we see fit.
- We will have sychronized releases of all application and framework components. If it's going to be a minor version release, only the modules that actually had any changes will be released. For major versions, all modules will be relased.
- Breaking backward compatibility will be documented, so that custom applications can be updated easily. Similar to what we started for Horde 4 in the wiki.
*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:
- Main development for the next release happens in the master branch.
- Only when the release process starts, we will branch off master, so that we can stabilize the code for the next release, while still going forward with development in master.
- Major, especially BC breaking changes will be done in topic branches, to not have the master branch polluted with instable code when the next release cycle arrives.
- The most recent two major version branches will be maintained with security fixes.
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.
