[cvs] [Wiki] changed: Horde3Development

[Chuck Hagenbuch]

chuck  Tue, 28 Dec 2004 09:43:01 -0800

Modified page: https://dev.horde.org/horde/wicked/display.php?page=Horde3Development
New Revision:  1.1

@@ -1 +1,15 @@
++ 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 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.