Story Time

As an engineer implementing the new release number cadence,

I want the various scenarios for release numbers identified and documented,

so we can tailor the release bumping and changelog generation algorithms appropriately.

Acceptance Criteria

• The use cases/scenarios for release numbers are identified and discussed in the team.
• A suitable* graph of commits is designed as a testbed for various scenarios. (*: small, acyclic directed)
• Findings relevant to the release bumping and changelog algorithms are documented.

Background

Beyond simply bumping it for package changes, the RPM release field can carry other information (e.g. with pre-releases, GIT snapshots, unsortable upstream versions), see: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning

Merging branches needs to "linearize" non-linear history, i.e. bring the commits in a chronological order in which changelog entries are generated.