---
tags: Automatic Release Field, Summary
---
# Summary: Approaches for Automatically Calculating the RPM Release Field

Small reminder:
* We aim for a Proof Of Concept/Prototype
* It will be opt-in
* We don't aim for 100% of the use-cases/packages
* We have 4 weeks left to work on this (deadline: end of March)

## Approach #1: `<#commits>.<#builds>%{?dist}`

Use the number of commits since last version bump, and the number of builds for the same commit for the same Fedora version, and append ``%{?dist}``.

### Notes

1. "Number of commits" must be (at least) the longest "path" from the commit back to when the version was bumped, e.g. in the case of merge commits. Could e.g. also be "number of all commits between this one and the version bump".
2. Uncommitted changes would have to be treated as one commit.

### Why?

1. Can easily be reproduced anywhere with access to the git repository.
2. Changelog entries can be mapped to version-releases by backtracking through git history.
3. Simplifies mass rebuilds because you can do any number of builds from the same commit.
4. The next release value is reliably and deterministically guessable before you submit a build.

### Why Not?

1. Only reliably allows opting in when the version is bumped. This excludes upstreams which don't receive version updates.
2. Needs the build system to know how many builds where done for a commit. Arguably, this doesn't matter locally as it only affects rebuilds.
3. A clean upgrade path can't be ensured. An older Fedora release may have more commits since the last version than a newer one, resulting in a higher release value for it.
4. In the described form, doesn't cater for snapshot releases, as the snapshot part needs to go between the release number and the dist tag.

### Requirements

1. Git history since at least the last version change (but we also need that for generating the changelog).
2. Build system information for number of builds for the same commit in the same Fedora version (or default to 1).
3. Relaxation or abolishment of the "clean upgrade path" requirement in Fedora.
4. An upstream version bump.

### Tweaks

1. Allow "priming" the number of commits with an offset to cater for upstreams that don't release new versions, working around Con 1 above.
2. Add options to the used macro to cater for snapshots which would add the snapshot information in between `<#commit>.<#build>` and the dist tag (Con 4).

## Approach #2: Using \[E\]VR Information of Existing Builds

Look at the existing latest builds in this and other Fedora versions, and determine a bumped release which satisfies a clean upgrade path, if at all possible (i.e. if there is a number range to fit things into). Allow users to specify information about snapshots, pre-releases, to be worked into the release field as described in the [Versioning Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning).

### Why?

1. Simplifies mass rebuilds because you can do any number of builds from the same commit.
2. Releases look familiar and grow at a similar pace than before, as what many maintainers do now is emulated.
3. Ensures a clean upgrade path, if at all possible.
4. Allows catering for snapshot releases as documented.
5. Allows opting in or out anytime.

### Why Not?

1. Needs the build system for information about builds in this and other Fedora versions.
2. Not easy to reproduce locally because we don’t have machine-consumable knowledge about other builds in e.g. the dist-git repo yet.
3. \[E\]VRs aren't easily determined for changelog entries unless you have access to the build system.

NB: All the above are essentially "needs access to the build system to do X".

### Requirements

1. Information about existing builds in different Fedora versions, this and others.
2. Therefore: Access to the build system.

## Tweaks

### Reintroduce Tagged Commits in Dist-Git

After a successful build, Koji tags the commit from which it built with e.g. `%{name}-%{epoch}:%{version}-%{release}`, ensuring that information about existing builds are available wherever you have access to the repository.

NB: exact type of git tag TBD.

#### Why?

1. No access to the build system is needed at all in order to get to the same results everywhere. This modified scheme doesn't care about number of builds, it just bumps.
2. Changelog entries can be mapped to version-releases by backtracking through git history.
3. Simplifies mass rebuilds because you can do any number of builds from the same commit.
4. The next release value is reliably and deterministically guessable before you submit a build.

#### Requirements

1. Koji would have to be made able to tag commits in dist-git.
2. Git history since at least the last version change (but we also need that for generating the changelog).
3. Upon introduction, the existing latest builds for Fedora versions we care about would have to be tagged. This can mean one mass event, or be done lazily, i.e. whenever people use the respective macro for the first time when building.
4. Package maintainers would have to be prevented from pushing tags into the dist-git repo themselves.