That's directly in opposition to the design and intent of %autorelease. Is there some specific use-case you have where the release has to be kept in sync with some other project (or something similar)?

Basically, the whole point of autorelease is to automate the release field; if you don't want that handled for you, why would you bother with %autorelease at all?

Sorry I didn't make my requirement clear. I didn't use %autorelease, but %autochangelog still generated one release for each commit. I like this %autochangelog feature because it allows me to get rid the boring job of copying the commit subjects and generating correct date. I wonder if it's possible to make %changelog to collect all commits after previous release if %autorelease is not used. In this way, it doesn't seem to go against the design of rpmatuospec.

For this use-case of kexec-tools, there are some Fedora-only development. That's why I usually make a build after several commits.

Mhm. %autochangelog is kind of optimized for use together with %autorelease: it doesn’t parse every single “version” of the spec file in its history to determine the release fields but simply plugs in the automatically counted release value. While doing the former is surely the more correct approach it’s also very likely to be noticeably slower (I haven’t tested this because I’d first have to implement it then 😁).

I’ll close this issue as the project has been moved to https://github.com/fedora-infra/rpmautospec some time ago. If this is still relevant, please open a ticket there.