---
title: Removing release and changelog fields, the idea and roadmap
tags: release-changelog
---

# Implementation idea and roadmap for removing changelog and release fields from spec files

## Idea of input and output

The next two paragraphs try to represent the idea of what the spec file should look like in dist-git and what it should become in koji.

Basically, the `%{autorel}` macro gets defined at the top of the spec file in koji and returns the output of the logic figuring out the next release for the package.
The `%{autochangelog}` macro gets entirely replaced by the changelog as generated from the git history as well as the `changelog` file stored in dist-git.

### Spec file in dist-git:

[...]
Release: %{autorel}

[...]
%changelog
%{autochangelog}

### In koji, spec file becomes:

%global function autorel() {
  return 1%{dist}
}

[...]
Release: %{autorel}

[...]
%changelog
* Mar 3 2020, pingou <email@domain> 1.2-1
- Update to 1.2

* Mar 1 2020 Nils <email@domain2> 1.0-1
- Update to 1.0

* rpmbuild -bs (koji builds the source rpm)
* rpmbuild -ba (koji builds the RPMs)
* If ^ succeed, we tag the nevr in dist-git

## Todo, logic and UX

TODO:
-----
* Rename the generate_changelog project to rpmautospec [pingou]
* New API endpoint in pagure to create git tags [pingou]
* koji plugin post scm checkout [Adam]
* Plugin relies on rpmautospec
* koji plugin post rpmbuild [Adam]
* Plugin calls pagure's API to add the new (git) tag
* Cook up/Polish the logic to find the next release [Nils]
* Docs on how to call rpmautospec from the koji plugin to do the work [Nils]
* Package rpmautospec (at least scratch build so we can install it in staging) [Nils]

* Patch fedpkg/rpkg to use rpmautospect as well [todo later]

rpmautospec's logic:
--------------------
* V0.1:
* Retrieve the git tags
* Computes the next release
* Insert the macro defining the release at the top of the spec file
* Generates the changelog using the git history between HEAD and the latest commit touching the `changelog` file
* Append the changelog to the spec file by inserting it where the macro is defined

* V0.2:
* Check the last builds in every active Fedora/EPEL release
* Check if these builds are tagged in the git repo
* If not add them using pagure's API

Opting-in:
----------
* Only in Staging: Tag old releases/builds to the repo (until rpmautospec v0.2)
* Add the 2 macros
* Move the existing changelog to the `changelog` file in the git repo

## Notes:
* Email announcing the idea (February 10th 2020): https://lists.fedoraproject.org/archives/list/[e-mail]/thread/IOUYM4GYMG64GBLPBJD6OEEU5EAXKXGC/
* Email about thee different approach considered (February 24th 2020): https://lists.fedoraproject.org/archives/list/[e-mail]/thread/FDARFS2KRWG7VAAPJYKJGUV6MEOH5P74/
* Approaches considered:
* [<#commits>.<#builds>%{?dist}](https://hackmd.io/lp-9tq-UQXKQA4G0PEQN3w#Approach-1-ltcommitsgtltbuildsgtdist)
* [Using [E]VR Information of Existing Builds](https://hackmd.io/lp-9tq-UQXKQA4G0PEQN3w#Approach-2-Using-EVR-Information-of-Existing-Builds)
* [Annotated tags pushed by maintainers](https://hackmd.io/kIje9yXTRdWITwP7cFK2pA#Annotated-tags-pushed-by-maintainers)
* Summary of the meeting of March 2nd 2020: https://hackmd.io/eHbnYTL_Q-KJwVeT-CuJRA?view