[dev] Development with Horde 3.0

[Chuck Hagenbuch]

Here are the guidelines for developing with Horde 3.0 and beyond. They will be
posted to the Horde Wiki (http://wiki.horde.org/) for reference.

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 in the version string,
you need Horde 3.x to run it. If you see H4, then you'll need a whole new (at
this point completely theoretical) Horde 4.x install.

- Avoid breaking backwards compatibility like the plague. If you need a change
in an API, do it by introducing a new framework package. If that won't work,
then we'll talk on 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
in which BC will be allowed to be broken), then we'll do it. But we want to
keep developing with this set of APIs and apps as long as possible to polish
them, making quicker feature releases, upgrading packages as needed.

- All bugfixes /must/ be merged into the FRAMEWORK_3 branches. bugfixes will go
into the 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 with a base Horde 3.0 install, with
the exception that if you only require newer versions of some framework
packages, which are otherwise BC-compatible (only new features or bugfixes),
that change is allowed.

- Once we release a new minor version of an application, the FRAMEWORK_3 branch
of that application will be updated to that release from HEAD (essentially
re-branching by merging), and the point (bugfix) releases will 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
as to what the version number is referring to.


Nothing here is set in stone; it's what's been worked out among the core
developers for how we want to handle development. The core goals are to make
Horde 3 a stable base for a long time, on which we can do frequent releases and
speed up development of new features that don't require breaking backwards
compatibility. Suggestions and comments are welcome.

Thanks for reading through,
-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John Quincy Adams