[dev] hordectl and horde-components

[Ralf Lang]

Hello colleagues,

I am close to stabilizing the hordectl and horde-components apps in a way
that I can safely distribute the phars along with some manuals so core
developers can leverage them the way I do and stop trying to manually edit
composer.json or the likes.

hordectl is the tool to manage one specific horde installation through a
CLI. Setup resources like initial admin user, introspect typical setup
problems, test the DB connection configured in the app, dump demo users,
groups and permissions during a CI run, ...

horde-components is a framework developer tool which makes working with a
checked out git tree and a special type of developer installation very
similar to working with a monorepo. It automates many tedious and error
prone tasks. It natively talks to github etc etc.

I am not yet there but hope to reach that point after this weekend's round
of releases. I really need to reduce my role.


1) Dependency management.

I think amulet1 most prominently asked for escalating minimum dependencies
on release of new components and while I don't fully agree, he has a point.

So horde-components has a new command which updates the .horde.yml file's
dependencies to the latest versions found in the local git checkout. I
still need to teach it some manners, don't downgrade because the local
checkout is old, double check if the found version actually exists as a
tag... it's not yet production grade.

  $ ./bin/horde-components package dependencies update --pretend
  Checking dependency versions in FRAMEWORK_6_0 branches...

  Dependency Updates [PRETEND MODE]:
    horde/autoloader: * → ^3 (from version 3.0.0-alpha5)
    horde/argv: * → ^3 (from version 3.0.0-alpha8)
    horde/http: * → ^3 (from version 3.0.0-beta2)
    horde/pear: * → ^1 (from version 1.0.0-alpha14)
    horde/role: * → ^2 (from version 2.0.0alpha4)
    horde/text_diff: * → ^3 (from version 3.0.0alpha5)
    horde/util: * → ^3 (from version 3.0.0-alpha9)
    horde/injector: * → ^3 (from version 3.0.0-alpha12)
    horde/version: ^1.0.0-beta1 → ^1 (from version 1.0.0-alpha3)
    horde/yaml: * → ^3 (from version 3.0.0-alpha5)
    horde/hordeymlfile: ^0.0.1-alpha3 → ^0 (from version 0.0.1-alpha3)
    horde/eventdispatcher: * → ^1 (from version 1.0.0-alpha2)
    horde/githubapiclient: * → ^0 (from version 0.0.1-alpha5)
    horde/composer: * → ^1 (from version 1.0.0-alpha3)
    horde/phpconfigfile: ^0.0.1-alpha4 → ^0 (from version 0.0.1-alpha5)
    horde/horde-installer-plugin: ^2.6 → ^3 (from version 3.1.0)

Once I see this works reliably I will put it into the default release
pipeline so a new release of component A will require the latest known
COMPATIBLE release of component B

We will need to discuss if we want to limit this to feature level or down
to patch level.

2) Generating composer.json from .horde.yml

This has been part of the release pipeline command for a while but it's
also available as a standalone command horde-components.phar composer

It completely rewrites composer.json from .horde.yml file and other knowns.
On release branch, it currently adds | dev-FRAMEWORK_6_0 to dependencies
but on feature branch it doesn't. This is by purpose.

We will also remove this behaviour once enough libraries have the new
approach of branch aliases. Basically we add new metadata to composer.json
so it knows FRAMEWORK_6_0 is the relevant major release for this framework
version - i.e. v7.x for IMP, v5.x for passwd and so on. No more need to
explicitly name the branch.

3) Generating releases and tags

This is part of the release process along with updating .gitignore,
changelog.yml etc.
I will describe shortly. I just want to make sure you understand this will
not stay with me personally for long and you will have the necessary access
for these operations.