release group metadata
This is spun out of issue #1. We want a way to define a release group so we can tell which projects are part of "plasma" or "frameworks" or "calligra".
The current best approximation we have of that are the CI's product definitions: https://invent.kde.org/sysadmin/ci-tooling/-/blob/master/local-metadata/product-definitions.yaml
Use cases:
- group of CI jobs
- kdesrc-building of a given product group (e.g. plasma)
- releasing a group
The IMHO tricky thing with grouping projects in general is that one project can be multiple groups albeit with different branches.
Let's imagine kmag was released independently originally (extragear, as it were) and after the 1.0 release was moved into the release-service instead. Until the first stable service release the "stable" branch of kmag continues to be independent while the "trunk" branch is part of the release-service. This is of little importance to the CI, but is acutely relevant information to the actual release tools. Currently all of them effectively have to carry a hard coded list of which projects ought to be released with a given release group.
As such we'll want to divide grouping by their i18n branches, which in essence act as the differentiation between "this is where development happens" and "this is where maintenance happens".
Proposed extension to the project metadata:
path: accessibility/kmag
...
i18n:
kf5:
stable: foo
trunk: master
release-groups:
kf5:
stable: independent # used to be self-managed
trunk: release-service # was then moved into release service; stable will be reset by the service tooling