attachment
rpmdev-newver

Hm, some logic needs to be added to reset Release to 1 ...

Instead of adding a new tool for this, I suggest adding an option to bumpspec for it.

Ah, I should have looked here before.

I worked on a similar idea which I put there: https://github.com/pypingou/rpmdev-bumpver

Hope this can help.

ping ?

ping?

I'd still prefer just improving bumpspec to handle this instead of adding a completely new script with very similar functionality (and which grabs the packager user+email slightly differently etc).

Any activity here? It would be a really nice feature.

A simple patch to support --new-version
new-version.patch

The attached patch would break the Fedora pre/post/snapshot release versioning scheme and, for example, would replace 0.4.alpha1%{?dist} with 1alpha1%{?dist}.

I've committed a slightly different change, which resets the entire Release tag to '1%{?dist}' unless a different release value is passed as an argument in V-R notation (such as 2.0-0.1.rc3%{?dist}). Being able to specify the Release value gives more freedom.

Repeating the new version number in the changelog entry comment is not necessary, since the latest EVR is added at the left of the entry automatically.

This --new option will only work with very simple spec files, however (which don't use lots of macros to define Version/Release and which don't define a varying Version for subpackages).

Replying to [comment:9 mschwendt]:

The attached patch would break the Fedora pre/post/snapshot release versioning scheme and, for example, would replace 0.4.alpha1%{?dist} with 1alpha1%{?dist}.

I've committed a slightly different change, which resets the entire Release tag to '1%{?dist}' unless a different release value is passed as an argument in V-R notation (such as 2.0-0.1.rc3%{?dist}). Being able to specify the Release value gives more freedom.

That sounds good.

Repeating the new version number in the changelog entry comment is not necessary, since the latest EVR is added at the left of the entry automatically.

As the changelog line is reused by tools like fedpkg commit -c, it's useful to include the version as well. Otherwise you and up with 'new version' as the commit message which is not very nice.

See:

https://fedoraproject.org/wiki/User:Pavlix#Bump_a_rawhide_package_to_a_newer_version

Replying to [comment:10 pavlix]:

As the changelog line is reused by tools like fedpkg commit -c, it's useful to include the version as well. Otherwise you and up with 'new version' as the commit message which is not very nice.

Agreed, but that's something that needs to be addressed in fedpkg commit -c, not here.

Replying to [comment:11 scop]:

Replying to [comment:10 pavlix]:

As the changelog line is reused by tools like fedpkg commit -c, it's useful to include the version as well. Otherwise you and up with 'new version' as the commit message which is not very nice.

Agreed, but that's something that needs to be addressed in fedpkg commit -c, not here.

I don't see any problem with fedpkg's behavior. It's just using whatever has been added to the changelog as a commit message. What would you expect it to do in this case?

Including the upstream version number in the changelog is IMO a natural thing and it would help maintaining commit messages helpful with no extra effort. On the other hand, I don't see any disadvantages.

While upstream version is part of the NVR at the top of each changelog entry, the fact that we are switching to a new upstream version is an information on its own.

Let's not go in circles, please.

See comment 9. The version number to insert in an automatically generated %changelog comment cannot be determined due to Fedora package versioning schemes. It would only work reliably when %{version} is exactly the software version - sure, that would be true often enough, but would not cover all cases.

If you want to specify the new software version in the changelog comment, use option -c COMMENT.

Replying to [comment:13 mschwendt]:

Let's not go in circles, please.

See comment 9. The version number to insert in an automatically generated %changelog comment cannot be determined due to Fedora package versioning schemes. It would only work reliably when %{version} is exactly the software version - sure, that would be true often enough, but would not cover all cases.

Good defaults are not always about covering all cases. That's why there is the -c COMMENT option after all. We're not going in circles, we just have different opinions and mine (1) happens to be of smaller importance and is (2) more about convenience than anything else.

If you want to specify the new software version in the changelog comment, use option -c COMMENT.

That's exactly what I'm doing, see:

https://fedoraproject.org/wiki/User:Pavlix#Bump_a_rawhide_package_to_a_newer_version

the rpmdev-bumpver proposed command looks just like rpmdev-bumpspec -n <version>? Do we still need this?

No, seems the "-n" option does job.