I'm not sure whether we want to support Release tags that look like they aren't compliant with the Packaging Guidelines?

There are documented ways to do more complex things (like setting and using %baserelease) that work with rpmdev-bumpspec, I don't particularly like adding more complexity here just to cater to use cases that either 1) are not correct Release tags in Fedora or 2) can be solved already in a different way.

Either %baserelease or %release_func can be set up to insert your macros like this (and also as to include minor bumps on the right side):

%{!?baserelease:%define baserelease() %{lua:
local r = rpm.expand("%1")
local rel = string.sub(r,string.find(r,"^%d+"))
local post = string.gsub(r,"^%d+","")
print(rpm.expand("%{?relprefix}" .. rel .. "%{?prerel}%{?dist}" .. post))
} %{nil}
}
Release: %baserelease 42

Let me give me background here:
We have to maintain various RHEL minor versions for packages on fedora. And there are various packages follow these types of Release tags. And when I am using this utility, it was not working as intended. I do not why packages follow these kind of tags and we will have to change lots of spec files.

If we can modify change this utility then it will be more useful and will reduces human error and could be use in automation.
I think this was main purpose of this utility and if we can add more use cases w/o breaking existing then there is no harm.
in the end, decision is yours. And will not bother you and follow further.
if there is issue in changes and it is breaking then you do not merge then it is ok.
but if some specs are not compliant with existing Fedora versioning because of that you are not taking, then it defeats the purpose.

Thank you very much.

When you talk about "automation", what is the typical workflow during a version change? How much do you automate actually with regard to choosing a new version or snapshot and downloading/generating the corresponding source tarball?

Why not automate the creation of a human-readable pair of Version and Release to use inside the spec file? Why introduce custom variables/macros that must be defined elsewhere (because the Release tag line is a mix of macros and a hardcoded number afterall) in ways that differ compared with other spec files?

Anyway, ultimately I leave the decision whether to modify rpmdev-bumpspec to the team that still use the tool during mass-rebuilds. I don't do those rebuilds anymore. But as pointed out in the PR, the regexp you've proposed is very generous in what it ignores while trying to bump a number hidden in the Release tag.

We bump the versions this way very frequently for packages for important bug fixes and CVE. Instead of complete version update, we update the rightmost digit or minor version. We get the changes from upstream and do backport to downstream so we have to do bump version this way everytime, when new build is created. We can use this utility in our workflow for automating some of repetitive tasks.

I'm just curious why you would use a pattern for this purpose that's not supported by the tools you use :sweat_smile:

See I am maintainer not product developer. So I am not sure why it was set
like this. But when I was using this utility it did not work as intended.
So if we can make this utility useful for other use cases then there is no
harm. And I see it as another use case or boundary case.

On Tue, 18 Feb, 2025, 23:14 Fabio Valentini, pagure@pagure.io wrote:

decathorpe commented on the pull-request: rpmdev-bumpspec is not bumping major version instead bumping minor version that you are following:
I'm just curious why you would use a pattern for this purpose that's not supported by the tools you use :sweat_smile:

To reply, visit the link below or just reply to this email
https://pagure.io/rpmdevtools/pull-request/120

We bump the versions this way very frequently for packages for important bug fixes and CVE.

Of course. But that doesn't answer how for example you modify "Version", which is hardcoded in your spec file, and the various macros that are used within "Release"? It seems to me the recurrent workflow involves manually editing EVR details and macros and patches in the spec file while also trying to use a tool that bumps "Release" in one out of multiple ways you choose depending on what type of package update it is.

I understand that your macros %{?relprefix} and %{?prerel} and possibly more EVR related ones get evaluated elsewhere in the spec file as to reduce the number of places you need to edit. Hopefully it works well for all tags like Source0, and for Fedora there are extra requirements like %commit and %shortcommit in case of packaging a snapshot. The better approach in my opinion would be to relocate the automated steps into a script that generates a more human-readable "Release" tag, which would be supported by rpmdev-bumpspec regardless of whether you want option -r or even -n.

Btw, bumping release in the least-significant right-most position in case of a security update is being frowned upon.