So, thinking about this for a few minutes I have this:

rpmdev-bumpspec should

• not modify the spec file at all if it detects %autorel or %autochangelog (or no %changelog section at all, if this feature is implemented in rpmautospec as well)
• exit gracefully, and exit code should probably be 0 to not make scripts fail
• print a helpful message to stderr (or to stdout?) that it did not modify the .spec file because rpmautospec features are in use

Did I miss something?

~~No, that sounds right.~~ Actually, if %autorel/%autorelease doesn't exist and there's no %changelog section, it should still bump the release, but otherwise it looks right.

https://pagure.io/rpmdevtools/pull-request/86 was merged and rpmautospec is deployed and is starting to be used, so could we have a new release of rpmdevtools for Fedora 34+? At the latest, this needs to be stable before the Fedora 35 mass-rebuild to avoid mass-garbled .spec files.

Yeah, I'll work on a release today.

I think this issue is fixed?

What is the simple way now to auto-update version field or any other things using rpmautospec? I am new to using rpmautospec.

Recently one of my package moved to use new auto macros. I have been successfully using my simple shell script to get version information from bugzilla title, pass it to rpmdev-bumpspec, upload new version tarball, commit and build the package. Everything happening automatically when I used to run script. But now rpmdev-bumpspec complains RPMAutoSpec usage detected

@pnemade "rpmdev-bumpspec --new" has already been fixed (by me) in the main branch: https://pagure.io/rpmdevtools/c/0bac8cc7a91939dc58d0f37c602d89b8b8bb40a1?branch=main

This commit just hasn't been part of a release, and so hasn't been pushed as a Fedora update yet.

However, if your scripts are using something like "fedpkg commit -c" to automatically generate the commit message for the version update, you obviously might still need to adapt them (because with rpmautospec, RPM changelog messages are generated from the commit message, not the other way round).

@ngompa should we tag a new release and push it to Fedora? This would also fix the-new-hotness issues with rpmautospec.

The only thing holding up a new release is https://pagure.io/rpmdevtools/pull-request/51 right now. I'm waiting for @salimma to get back to me on this and then I want to cut a release.

Gentle ping, I think all prerequisites for tagging a release are now met.

Oh yep, I'll get this going today.

@ngompa would it help you if I tagged a release and submitted updates for Fedora? :)

This is done and released.

F35: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e105d54f20
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a152466830