Over-versioning in %autochangelog

[mcrha]

Coming here from https://pagure.io/rpmdevtools/issue/127

When a package uses %autochangelog, but does not use %autorelease, the generated changelog can get out of sync with the real version. You can find out the correct version, the old commits are proof of that, but when there are bare commits without an actual build (and without a version bump), then you bump the version and get out of sync.

Furthermore, the above bug has a case where the Fedora mass rebuild wrote a correct version into the %changelog (that bug is about not writing into the %changelog when the %autochangelog is used, which they do not do only if also %autorelease is used at the moment), but the %autochangelog rewrote it and bumped the changelog version to its liking.

From my point of view, consecutive commits without a build can generate a single entry with joined all of the commit messages up to the one which bumps the version. Not that you can figure any such thing with %autorelease, but then maybe you can assume the build happened, just as you do now.

[decathorpe]

I think this would boil down to "if the Release tag is not %autorelease, then don't use the commit history for determining the Release part of the %changelog entry, but use the actual Release tag instead"?

[Conan-Kudo]

Most of this comes from our policy that the EVR needs to be present in the changelog entry, since there's otherwise no way to tell.

[mcrha]

I think this would boil down to "if the Release tag is not %autorelease, then don't use the commit history for determining the Release part of the %changelog entry, but use the actual Release tag instead"?

As I said, it's already there, the old commits (for previous versions) have set the version in the changelog properly. From that I believe it knows how to get to the version the commit is made for.

since there's otherwise no way to tell.

No way to tell what, please? For which version the change happened? Yeah, that's true and makes sense.

[Conan-Kudo]

Yes.

[decathorpe]

As I said, it's already there, the old commits (for previous versions) have set the version in the changelog properly. From that I believe it knows how to get to the version the commit is made for.

And if you read what I wrote, I explicitly said Release, not Version :) the counting of Release numbers is (mostly) based on how many commits there were since the last time the Version was changed.

I meant to say "don't rely on this number for formatting the %changelog entry if Release is not %autorelease, just use the value from the Release tag directly".

[sgallagher]

I meant to say "don't rely on this number for formatting the %changelog entry if Release is not %autorelease, just use the value from the Release tag directly".

There's a subtle "gotcha" here, unfortunately. The Release: field may not hold the %autorelease tag in special cases such as Node.js.

Or do you think we should just conditionalize it on %autorelease appearing anywhere in the specfile?

[mcatanzaro]

Here's an additional gotcha

[sgallagher]

@nphilipp
I honestly question why people think %autochangelog without %autorelease should work at all. There are WAY too many edge cases around properly versioning the changelog for this to behave as expected.

The simplest solution would be for us to just drop the version from the end of the changelog (we'd still have the commit date at the beginning) if-and-only-if %autorelease is not present. Currently, this would throw a warning in rpmlint, but that would be something we could adjust.

* Tue Sep 02 2025 Stephen Gallagher <sgallagh@redhat.com>
- Drop the changelog version when %%autorelease is not used

[mcrha]

In my case it felt convenient to not duplicate the information in the .spec file, when it's already in the git history (the downside is that I cannot correct typos in the commit messages, not easily at least). I do not like duplication, which is the main motivation in my case. That I was not aware it's both or nothing is another thing (and kinda fault on my side).

Another solution could be to force usage of them both, to error out when the package .spec file uses only one of them.

[sgallagher]

In my case it felt convenient to not duplicate the information in the .spec file, when it's already in the git history (the downside is that I cannot correct typos in the commit messages, not easily at least). I do not like duplication, which is the main motivation in my case. That I was not aware it's both or nothing is another thing (and kinda fault on my side).

Another solution could be to force usage of them both, to error out when the package .spec file uses only one of them.

"Both or nothing" is overkill, I think. Using %autorelease to avoid dealing with Release bumps while still manually crafting the Changelog is a valid choice, I think (so long as the maintainer understands how to get the correct version from rpmautospec calculate-release. But the other way around doesn't really make much sense. It's not like we're running out of integers to use for the Release numbers, so why does it really matter if you go from foo-1.2.3-1.fc42 to foo-1.2.3-5.fc42? I mean, I understand the somewhat OCD need to carefully sculpt the output, but it's not actually necessary (and if you're going to that extent, you probably shouldn't be using rpmautospec at all).

I think the most effective solution here would be for us to still allow one or the other, but handle it more gracefully. %autochangelog without providing the version at the end of the entry header would be the easiest solution, rather than the current one which is to just treat the %autochangelog as following the rules of %autorelease without any arguments.

Another option would be to disallow the use of %autochangelog without a matching use of %autorelease. How we define "disallow" would have to be carefully considered. I think there are three choices what to do in this situation:

1. Have %autochangelog return an empty string.
2. Have %autochangelog return some placeholder text similar to the case where the git checkout is "dirty".
3. Have %autochangelog intentionally fail to parse, so that rpm throws an error.

[mcrha]

• Have %autochangelog return an empty string.

• Have %autochangelog return some placeholder text similar to the case where the git checkout is "dirty".

There are clearly wrong, I'd never notice it does some such odd/unexpected (by me) thing.

[Conan-Kudo]

The main issue is that Fedora currently requires a 1:1 mapping of build to changelog entries. openSUSE (which also does autogeneration of release, but not changelog) does not, and instead it is only expected that changelog entries exist for source changes. This is eventually where I want us to be in Fedora, but our tooling was not developed quite right for this and our policies need fixing for it too.

Notably, we need to make it mandatory to write in the changelog entry about version upgrades. It's currently conventional and not everyone does it. And it doesn't matter because the version-release is part of the authortext in the changelog entry. But if it wasn't anymore, then people must record the version bump in the changelog entry text.