+ 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
+++ CHANGES file
+++ 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