Horde Release Management
This section describes the release process of the stable Horde releases.
Horde 3.3 Release
Applications to be released along with Horde 3.3
- DIMP 1.1
- IMP 4.3
- Kronolith 2.3
- Nag 2.3
- Turba 2.3
- Hermes 1.0
- Whups 1.0
Applications to be released following Horde 3.3
- Ansel 1.0
- Chora 2.1
- Forwards 3.1
- Gollem 1.1
- Klutz 1.0
- Passwd 3.1
- Trean 1.0
- Vacation 3.1
- Wicked 1.0
Horde 4.0
The decisions made for Horde 4 so far are:
- Move to git for future (Horde 4+) version control. Code will be pushed to a clean git repository as it is modified for Horde 4 and PHP 5. Git pushes will generate email to a new list, commits@lists.horde.org. Everything currently in CVS will remain available, and Horde 3.x will continue to be developed in and released from the existing CVS structure.
- Aim for shorter release cycles of major versions. When backwards compatibility is broken we will increment the major version number (Horde 3 to Horde 4) as we do now; we'll just do that more often. Feedback indicates that being able to do feature upgrades of an application but not Horde, or vice versa, is not a big advantage for most people.
- Use individual package versions much more extensively with Horde 4. We want it to be possible to release an application upgrade that relies on new framework functionality without requiring a new major version; instead, many changes will be possible by just requiring a specific package version.
- Finally, and most importantly, we will be focusing on getting the last Horde 3.3 releases out (see above), and then shifting our major focus to Horde 4. Our goal is to have an initial release of Horde 4.0 within 6 months of starting serious development on it; and to aim for major version releases approximately every year thereafter.
Full minutes of the board meeting where this was discussed: http://lists.horde.org/archives/board/2008-October/000085.html
Git layout
We have three git repositories:
- horde
- horde-hatchery
- horde-support
We've imported framework/Support into the horde repository to have something there. More code will move there a bit slowly, faster as we sort out git support for Chora, etc.
All of the separate projects (hippo, hydra, crumb, Horde_Date_Parser) that were being stored in git or hg as tests have been moved into the hatchery repository.
The support repository has the git and svn hooks in it. Once we have update mechanisms in place, we'll add hordeweb there.
hordedoc is an open question.
Also, just a reminder that git push messages are going to commits@lists.horde.org, not cvs@lists.horde.org.
Mini-faq for Horde 4 development:
Q: Are we going to keep the existing development model where we have a "master" server (i.e. cvs.horde.org) where we will build the releases? For our workflow, that seems to make the most sense - since we don't have a "master" user that checks all commits before integrating.
A: Yes. We'll figure this out as we work on Horde 4, to some extent, but my expectation is that we will all push commits to dev.horde.org:/horde/git/horde (or horde-hatchery, etc.), and we'll use branches to do local dev or to coordinate non-mainline work.
Roadmaps
Horde
http://www.horde.org/horde/roadmap/
IMP
http://www.horde.org/imp/roadmap/
Turba
http://www.horde.org/turba/roadmap/
Ingo
http://www.horde.org/ingo/roadmap/
Kronolith
http://www.horde.org/kronolith/roadmap/
Expanded thoughts on using resources
Nag
http://www.horde.org/nag/roadmap/
Sork
- Merge passwd into framework/Auth library
- Merge vacation and forwards drivers with Ingo and Sam (see Ingo roadmap)
Chora
http://www.horde.org/chora/roadmap/
Older Releases