Horde 6 Release & CI Tool Design

Motivation

Horde 4 and Horde 5 used the components tool to run unit tests, quality tools but also to build releases and snapshots.
Maintaina used a modified version of the components tool to build releases both in the public repository and for non-public projects on gitlab

Having two versions of the release tool to maintain the PEAR based Horde 5 until EOL and the composer based Horde 6+ is awkward. While horde's official version of the components tool MAY be upgraded to support H6, it may as well not be needed.

The proposed design embraces github's pull request model without depending on github specific technology. It should be easy to adapt for gitlab or other technology.

Deprecated / abandoned operations

- package.xml and PEAR support
- CHANGES file
- bootstrapping a standalone CI

Required operations

- Generating next (major, minor, patch or alpha/beta/rc/dev) version string from current version string
- Updating version number in relevant files
- Building composer.json from .horde.yml
- Keeping a statically rendered satis composer repo and phpdoc
- Maintaining development quality data: Passed PHPUnit and PHPStan levels for different branches, PHP versions. Keeping code coverage reports
- Inferring a yaml changelog from key worded commits and/or pull requests (still allowing developers to deal with them manually)
- Inferring the need for a major, minor or patch release or a transition from dev to Alpha to Beta, RC, Stable from the changelog
- Building and tagging a release

Desirable operations not currently in scope

- Trigger for release specific additional work like mailing list, bug tracker grooming, social media blurb
- Rendering/updating files from WIKI content and templates