Story Time

As a member of FESCo or an engineer working on rpmautospec,

I want that release numbers are computed by simply counting out commits since the last version change,

because this relieves the code from having to maintain GIT tags for successful builds, improving robustness.

Acceptance Criteria

• Code exists which determines the release number for an RPM spec file in a GIT repository (as on https://src.fedoraproject.org).
• It uses the git command rather than 3rd party packages for git operations (like checking out previous commits to find the latest version bump).
• This code replaces the legacy heuristic holistic algorithm in the main code base.

Background

Algorithm

The release number is defined as: the number of commits since the last time the RPM version field was changed. The commit changing the version would map to release number 1, the next 2, and so forth. In the case of non-linear history (more than 1 branch being merged since the version change), the longest branch counts.

Ideas on how to determine the version change:
- Parsing RPM spec files in order to determine e.g. the Version field value will be hard and unlikely to be correct (meaning: not guaranteed to get the same result as RPM would), therefore let RPM do the heavy-lifting.
- We can query spec files in kind of the same way as packages, e.g. like rpm --queryformat '%{version}\n' --specfile somepackage.spec. This will yield results for the main and all subpackages, so we'll only look at the first line of output and disregard the rest.

Proof of Concept (optional)

While not everyone in the team is familiar with the existing code base, it could be implemented as a separate proof of concept first, not tightly integrated with existing code. There are helper functions like rpmautospec.misc.get_rpm_current_version(), though, which a) we should employ rather than reinvent the wheel, to b) ease integration in the main code base.

Legacy

The prototype created git tags for every so-called NEVR (name-epoch-version-release) that was built successfully (see e.g. the tag_package subcommand). The new scheme won't add git tags, or use their information anymore, so we can get rid of all code related to git tagging and doesn't force us to run important pieces in the build root when creating the SRPM in Koji.