Development » Modules
The following, maintained modules are in the Horde Git Repositories, with the listed production level available. If no version is listed, then there has not yet been a stable release of that module. If a module is not listed, but available as a repository, it's either not maintained at the moment, or this page is outdated.
|horde||5.2.17||The core Horde application||Production|
|framework||Horde Framework libraries||Production|
|ansel||3.0.8||Photo Gallery application||Production|
|chora||VCS (version control system) repository front-end||Production|
|gollem||3.0.12||Web-based File Manager||Production|
|hermes||H3 (1.0-RC2)||Time-tracking/billing data system||Production|
|imp||6.2.21||The IMP Webmail Client||Production|
|ingo||3.2.16||Mail filtering administration||Production|
|kronolith||4.2.23||Calendar and scheduling||Production|
|mnemo||4.2.14||A Memo/Notepad application||Production|
|passwd||5.0.7||Password changing module||Production|
|sam||A Spam Assassin module||Beta|
|sesha||H5 (1.0.0RC3)||Inventory manager||Beta|
|skeleton||A template for new Horde applications|
|ulaform||A form generation/processing tool||Beta|
|whups||3.0.12||A project management system||Production|
A note on stability
The master branch of an application module will almost always be development code, and may be unstable. The stability listed for each module is the general state of that module. However, just because that IMP and Horde are listed as Production quality software, doesn't mean that "master" will always work, be documented, compile, or not cause frogs to dive-bomb you from tall trees. You've been warned. ;)
A note on branches
The branch names for applications generally take one of these formats:
- master -- This is always the current development branch, and may be unstable and undocumented.
- FRAMEWORK_* -- These are always the current stable branches that contains bug fixes for the next release. Modules within the same FRAMEWORK_* branch are compatible with each other.
Framework library modules usually only contains a single master branch that may either contain bug fixes for the next stable release, or new features for the next feature release. Only if there are backward compatibility breaks, there may be additional maitenance branches for earlier major releases.