+ Horde 3 Development Guidelines These guidelines apply right now to Horde itself, the framework packages, IMP, Ingo, Chora, Nag, Mnemo, and Kronolith - all of the applications that have FRAMEWORK_3 branches and were just released. They will apply, in the future, to any application released to work with Horde 3.0 in a FRAMEWORK_3 branch. * All
applications that work with Horde 3.0 are tagged with H3 in their version numbers. This is for ease of identifying what Horde version you need to run a particular application. No more remembering that RELENG_3 of IMP goes with RELENG_1 of Turba and RELENG_2 of Horde. If you see H3 inthe version string, you need Horde 3.x to run it. If you see H4, then you'll need a whole new (at thispoint completely theoretical)Horde 4.x install. * Avoid breaking backwards compatibility likethe plague. If you needa change in an API, do it by introducinga new framework package. If that won't work, then we'll talkon the lists about what the change gets us and what the cost is. If it justifies making a move towards Horde 4.0 (which is the next version inwhich BC will be allowed to be broken), then we'lldo it. But we want to keep developing with this setof APIsand apps as long as possible to polish them, making quicker feature releases, upgrading packages as needed. * All bugfixes /must/ be merged intothe FRAMEWORK_3 branches. bugfixes will go intothe point releases -Horde 3.0.1, IMP 4.0.1, Kronolith 2.1.1 (eventually), etc. * All new features get committed to HEAD (again, not breaking backwards compatibility). New releases will be minor version changes - IMP 4.1, Horde 3.1, etc. All of these releases should work witha base Horde 3.0 install, with the exceptionthat if you only require newerversions of some framework packages, whichare otherwise BC-compatible (only new features or bugfixes), that change is allowed. * Once we release a new minor version ofan application, the FRAMEWORK_3 branch of thatapplication willbe updated to that release from HEAD (essentially re-branching by merging),and the point (bugfix) releaseswill still be made from the FRAMEWORK_3 branch. This is for consistency - the stable code that works with Horde 3 will always be in a FRAMEWORK_3 branch - and to avoid FRAMEWORK_3_0, FRAMEWORK_3_1, etc. as branch names, since that gets confusing asto what the version number is referring to. Nothing hereis set in stone; it's what's been worked out amongthe core developers forhow we wantto handle development. The core goalsare to make Horde 3a stable basefor a long time, on whichwe can do frequent releasesand speed up developmentof new featuresthat don't require breaking backwardscompatibility. Suggestions and comments are welcome.