Downstream Horde Development

Preface

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)

changelog.yml

A changelog in YAML format (all packages)

.horde.yml

See Developer Doc on .horde.yml format

CHANGES file

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)

Older releases of the components tool will use the package.xml file even though information could be pulled from .horde.yml file.
Newer releases of the components tool will not strictly require a package.xml - however, omitting this file will not allow releasing for PEAR, pear dependeny graph etc.

composer.json

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

See https://github.com/maintaina-com/horde-satis.maintaina.com for an example.