Last Modified 2019-04-18 by Ralf Lang (B1 Systems GmbH)

Downstream Horde Development


There are multiple purposes which require you to create software releases independent from the Horde upstream infrastructure. You may want to develop a feature for an existing app and rollout to some canary customer. You may want to develop completely new horde apps or libraries from scratch for some internal purpose or involving compromises which need to be fixed before a public rollout. You may want to maintain a set of permanent downstream modifications in a git tree while following upstream developments.

Each of these may require you to handle horde metadata and create releases by yourself.

Note that large and long-lived downstream forks may be more difficult to finally include in upstream development than piecemeal pull requests. However, sometimes it makes sense to cut on upstream interaction delays and get something done. This is especially the case if a feature involves changes to several core libraries.

List of relevant metadata files and items

Application.php version info

A variable in the main application file (only apps, not for components app itself)


A changelog in YAML format (all packages)



A plaintext CHANGES file (most packages)

PEAR package.xml

A pear package definition (all released H4/H5, all H4/H5 alpha, not for git-tools)


A composer manifesto (all recent packages)

Maintaining the Changelog

Bugfix releases (a.b.x -> a.b.y)

Feature Releases (a.x.c -> a.y.0)

snapshot pear tarballs

Private Composer Infrastructure