Using one without the other is bound to lead to problems. As such I would consider it bugs in the packages that do this.

Why? What would the problem be? I want some things under my control, "everything auto" is not always good.

I understood the %autochangelog just generates the change log from the commits. It seems to be able to know which version the commit belongs to, then it would not be able to mark the old commits properly, which it does set proper version for them, but I see it is dull and causes over-versioning, like in the gnome-software, where the package version is -2, but the changelog below in the page says -8.

From my point of view, the %autochagelog should group all the commits for the same version under a single entry; it's no problem when it's done in different days; again, from my point of view. That belongs elsewhere.

There is one interesting thing I just noticed with the links in the description. The commit bumped the version to 2 and wrote it as 49~alpha-2 into the %changelog section, but the releng build changelog section has that overwritten to 49~alpha.8, which looks like the %autochangelog tries to be smart and causes errors. Where is the bug tracker for the %autochangelog, please? I may open a case there for this.

Well ... you exactly outlined the problem with using %autochangelog but setting Release manually - they will get out of sync. Which is why I don't think we can reasonably support this use case.

Anyway, the only bug in rpmdevtools I see here is that rpmdev-bumpspec apparently still adds a %changelog entry even if %autochangelog is present. It should just fail, because it's impossible to tell what the packager's intention is in that case.

The bug tracker for rpmautospec is here: https://github.com/fedora-infra/rpmautospec

I do not think "it should just fail", the intention is clear, as a changelog use the commit messages.

I opened https://github.com/fedora-infra/rpmautospec/issues/311

No, the intention definitely isn't clear. I have never seen a package that did this intentionally until you linked an example a few comments earlier, I only saw instances of this case where it happened accidentally.

The documentation for the autochangelog mentions the autorelease only once and not in a way which would even suggest to use both or none in the spec file. The intention is clear from this documentation ;)

I am not sure if the condescending tone was intentional, but it doesn't make me want to help you here. I have experience with both rpmdevtools (heck, I wrote spectool! ...) and a lot of experience with rpmautospec. You could just believe me when I say things regarding these two ...

Oh, I really did not mean anything offensive, hence the smiley at the end of the paragraph.

To be honest, it makes sense to use the two together, just as you said, I only wanted to use just one of them, to save writing the text into two places (in the spec and in the commit messages). That it's both or nothing wasn't clear to me, I've been surprised of that position you stated.

I can revert those changes (I made it in multiple packages), it only felt like it's doable to improve the tool when only one is used.

Yes, rpmdev-bumpspec should not create broken spec files in this case.

But I still don't think using one without the other is a good idea.

Okay. If you do not mind, I'll wait a bit before I'll revert the changes in those packages (it'll be fun to recall all of them, I did it in some I usually take care of, but also in others; maybe I'll add autorelease to those other packages, I will see, I'm not sure yet). I'd like to wait for the result of the rpmautospec bug I filled (https://pagure.io/rpmdevtools/issue/127#comment-980388) and maybe also this bug, if anybody will take it (I understood you won't, but please believe me I did not want to upset you, I'm sorry about that).

Well, that's annoying ... I wish you had asked about this before making changes to a lot of packages :(

I did not want to upset you, I'm sorry about that

It's ok. Communicating intent (and humor) on the internet is hard ...

If I have time, I'll take a look at rpmdev-bumpspec why it does behave the way it does.