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 <user@foo.com>
- 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 <user@foo.com>
- 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 <user@foo.com>
- 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 <user@foo.com>
- 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:
Add a feature to
changesgeneratethat 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 reusingversionrewrite-pattern.Rationale
Some upstream projects tag releases more frequently than the package maintainer can make package updates in OBS. The best
changesgenerateUX is when top level entries correspond exactly to upstream tagged releases. Currently, if the package maintainer skips one or more upstream tags,changesgenerateentry combines all git commit messages since the previous entry in_servicedataunder the latest tag.Example
The current behavior when the maintainer changes
revisionfromv3.4.0directly tov3.4.2, skipping upstream tagv3.4.1:The preferred opt-in behaviour would be to create separate entries for each tag encountered:
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.
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
versionrewriteor 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:
Configured to limit tags to tagged releases in a specific format: