I am very sorry $lead.$follow doesn't feel satisfying.

The thing is that rpkg auto-increments only the last number in version string (e.g. 0.0.0) based on the last annotated tag made. So when you make a new tag with rpkg tag, you will get an increment in that last component. The first two numbers need a manual update. They basically represent some bigger event in the given software and are assumed to be incremented by an explicit request of a software maintainer.

Even though, rpkg doesn't exactly mirror the major.minor.patch structure of semver, I did $lead and $follow with big consideration to that structure. Basically, from rpkg's point of view, version has two parts:

• "fixed" (specified by maintainer)
• "auto-generated" (generated by rpkg unless specified by maintainer)

Those parts are named "$lead" and "$follow", respectively.

"$lead" is expected to have a richer structure if maintainer follows semver. While I very much agree with semver versioning, maybe just two numbers are ok too for a simpler software? i.e. breaking changes vs. non-breaking changes.

But my main point was that I wanted to put into rpkg really just the essential functionality so that it basically becomes rock-solid and in this case I felt a need to really just recognize only two components (fixed vs. dynamic) instead of three to provide an auto-incrementing behavior.

Mirroring semver one to one in rpkg would make sense to me if we would be able to increment both, the middle (minor) number and also the patch number but that's, I think, only possible if the patch number is incremented by each commit and the minor number by each tag. But that would mean you wouldn't be able to tag patch releases because the last component would always immediately reset to zero upon a new tag.

I hope I am making sense here :). If not, just tell me. This matter might require more communication to be properly transferred :).

Is there any reason rpkg can't be configured to just pick up the version number from a custom > tag? Meaning if I run 'git tag -s foobaz-release-1.0.1' and then rpkg will pick up the version? You > would need something like {{{ git_dir_version exclude=foobaz-release- }}} to obtain the version > and then place that into the spec. This will allow folks to use whatever versioning scheme they > wish.

rpkg does read the version from the latest tag of a matching $name-$lead prefix. So if you create a new tag manually* (should be annotated), it will pick up the version from that tag (if $name-$lead of the tag matches what is in spec file).

(by *manually, I meant that you explicitly specify the whole name of the tag)

I hope this is not too complicated. I tried to do the whole thing as simple as possible but the documentation could be richer and it requires some "getting-into", especially if one wants to customize stuff.

I value you feedback very highly, by the way, so if you have next comments/questions/bug reports, please tell.

Is there any reason rpkg can't be configured to just pick up the version number from a custom tag? Meaning if I run 'git tag -s foobaz-release-1.0.1' and then rpkg will pick up the version? You would need something like {{{ git_dir_version exclude=foobaz-release- }}} to obtain the version and then place that into the spec. This will allow folks to use whatever versioning scheme they wish.

I've just realized that you would like even the $lead part to be derived from the latest tag, not only the $follow part.

...That makes a good deal of sense to me, especially for projects that would like to maintain the spec file "by-the-way", i.e. they don't want to edit it to increment the lead component.

One quick idea that comes into my mind is to allow an empty "$lead", i.e.

{{{ git_dir_version lead= }}}

and checking the code in the master branch...it could already work in the way you expect :).

I am not completely sure. If you have time could you, please, check the 3.prototype.git.145.60c7000-1 version from the rpkg-util copr if setting empty lead behaves how you expect?

Ping erinn, could you confirm everything is alright for you here?

standby, I do intend to get back to this, personal life has intervened.

standby, I do intend to get back to this, personal life has intervened.

No problem.

Yeah this works with the 3.prototype.git.145.60c7000-1 version. I'd suggest a couple of things, document out the sytax that will be required for rpkg to pick it up, as well you unfortunately lose the automatic changelog, so perhaps document how to manually enter in the changelog so that it is picked up.

If I can also make a suggestion, though it is nice that :
{{{ git_dir_version lead= }}}
works out of the box, perhaps something more along the lines of:
{{{ git_dir_version lead=manual }}}
would lend itself towards more clarity about what exactly is going on.

Just my thoughts.
Thanks,
-Erinn

Yeah this works with the 3.prototype.git.145.60c7000-1 version. I'd suggest a couple of things, document out the sytax that will be required for rpkg to pick it up, as well you unfortunately lose the automatic changelog, so perhaps document how to manually enter in the changelog so that it is picked up.

I don't think setting lead to empty should lead to loss of changelog :). Do you have the project somewhere public so that I could take a look. The changelog really stopped displaying after using lead= ?

If I can also make a suggestion, though it is nice that :
{{{ git_dir_version lead= }}}
works out of the box, perhaps something more along the lines of:
{{{ git_dir_version lead=manual }}}
would lend itself towards more clarity about what exactly is going on.
Just my thoughts.

Right, I was thinking about this. The problem is if someone would want to lead which is called manual, i.e. i would prefer the implementation not to use the "reserved" keywords.

Thanks,
-Erinn

Erinn, thank you very much for the contribution/feedback. Please, let me know if I can do anything else here.

This issue has been migrated to GitHub: https://github.com/fedora-copr/rpkg-util/issues/25
Don't forget to subscribe for notifications about new comments.