Enable changesgenerate to create a new top level entry per git tag encountered

[jfkw]

Add a feature to changesgenerate that can optionally create a top level entry per matching git tag encountered. For control in excluding beta, rc and PR-related tags, the git tag encountered should match a version format regex similar to or reusing versionrewrite-pattern.

Rationale

Some upstream projects tag releases more frequently than the package maintainer can make package updates in OBS. The best changesgenerate UX is when top level entries correspond exactly to upstream tagged releases. Currently, if the package maintainer skips one or more upstream tags, changesgenerate entry combines all git commit messages since the previous entry in _servicedata under the latest tag.

Example

The current behavior when the maintainer changes revision from v3.4.0 directly to v3.4.2, skipping upstream tag v3.4.1:

-------------------------------------------------------------------
Wed May  1 04:32:07 UTC 2024 - Jeff Kowalczyk <[email protected]>

- Update to version 3.4.2:
  * test: fix invalid pkg case
  * test: add another cascade case
  * Fix substitution rule parsing (#813)
  * chore(deps): bump golang.org/x/net from 0.17.0 to 0.23.0 (#809)
  * docs: add Digital Ocean
  * fix: fallback to default config when syncing
  * feat: add `capitalize` option in `substitution`
  * fix: only match case for `ignorecase: true`
  * docs: add demo screenshot [ci skip]

The preferred opt-in behaviour would be to create separate entries for each tag encountered:

-------------------------------------------------------------------
Wed May 01 03:45:27 UTC 2024 - Jeff Kowalczyk <[email protected]>

- Update to version 3.4.2:
  * test: fix invalid pkg case
  * test: add another cascade case
  * Fix substitution rule parsing (#813)
  * chore(deps): bump golang.org/x/net from 0.17.0 to 0.23.0 (#809)
  * docs: add Digital Ocean

-------------------------------------------------------------------
Mon Apr  8 10:55:40 UTC 2024 - Jeff Kowalczyk <[email protected]>

- Update to version 3.4.1:
  * fix: fallback to default config when syncing
  * feat: add `capitalize` option in `substitution`
  * fix: only match case for `ignorecase: true`
  * docs: add demo screenshot [ci skip]

In the above example the timestamps are taken from the tag GIT_COMMITTER_DATE . This feature request (another opt-in configuration) will be filed separately but is referenced here.

Another configuration option could be to create separate top level headings, sharing the timestamped header using the current behaviour of current time. This may be preferable for some maintainers, or situationally to work around timestamp ordering issues such as when packaging has made changes between upstream tagged releases.

Example of shared header, separate top level headings.

-------------------------------------------------------------------
Wed May  1 04:32:07 UTC 2024 - Jeff Kowalczyk <[email protected]>

- Update to version 3.4.2:
  * test: fix invalid pkg case
  * test: add another cascade case
  * Fix substitution rule parsing (#813)
  * chore(deps): bump golang.org/x/net from 0.17.0 to 0.23.0 (#809)
  * docs: add Digital Ocean
- Update to version 3.4.1:
  * fix: fallback to default config when syncing
  * feat: add `capitalize` option in `substitution`
  * fix: only match case for `ignorecase: true`
  * docs: add demo screenshot [ci skip]

Control over matching git tags

Upstream projects often have prerelease or workflow managed tags that the packager is not interested in, e.g. beta, rc, PR. Use the regex in versionrewrite or a related parameter to limit which tags trigger a new top level entry when encountered. I need to familiarize myself with those related pararmeters, but something like the following would be the idea:

Current behaviour:

    <param name="changesgenerate">enable</param>
    <param name="versionformat">@PARENT_TAG@</param>
    <param name="revision">v3.5.0</param>
    <param name="versionrewrite-pattern">v(.*)</param>

Configured to limit tags to tagged releases in a specific format:

    <param name="changesgenerate">enable</param>
    <param name="versionformat">@PARENT_TAG@</param>
    <param name="revision">v3.5.0</param>
    <param name="versionrewrite-pattern">v([0-9]+\.[0-9]+\.[0-9]+)</param>