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




PEAR package.xml


Maintaining the Changelog

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

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

Private Composer Infrastructure