Hello, yesterday, I was updating documentation for rpkg macros (https://docs.pagure.org/rpkg-util/macro_reference.html) and I noticed that maybe, the behavior of git_release macro could be improved. This is a bit long question because I need to describe some details... intro ------ git_release macro is an rpkg macro that generates release in rpm spec file from git history. More precisely, it reads the latest annotated tag (which has N-V-R form) for a given package to know what is the latest release number. That number is then rendered out when spec file is being preprocessed. If RELEASE_BUMP environment variable is set, this number is incremented by one and only then it is rendered out. In spec file, usage of the macro looks like this: Release: {{{ git_release }}} Note that git_dir_release is actually the recommended form for use, which functions the same in this context, however. So I am using git_release to keep things simpler to explain. Recently I have added prefix= parameter to the macro to be able to specify git branch name as a release prefix. To give you the idea, here are some examples of generated releases when prefix is used: master.1, f32.3, epel8.2, ... Currently, the macro header looks like this: git_release name= prefix= pivot= name - name of the package prefix - static release prefix pivot - dynamic release part which is being auto-incremented problem ----------- Now the thing is that there is also git_version macro, which is meant to be used when you put spec file into upstream sources directly and you want to dynamically derive Version from git history, not Release. The header of the macro looks like this: git_version name= lead= follow= name - name of the package lead - major version of the package (possibly multipart), assumed to be manually incremented on API/ABI changes follow - minor version number which is being auto-incremented I am thinking I can make the interface of those macros (git_version and git_release) the same. I.e. update git_release to also have lead= and follow= input params instead of prefix= and pivot=. I was thinking about it already several times but before there was no prefix= and I didn't see the need to have more than one parameter for git_release until https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/MTH3YF2V3RRCQPJRU23GUZ2G3XYH2DKJ/, that's why I kept them separate implementation-wise. But now it seems they could be unified which would also simplify the code. The only difference would be that git_version would work with V part of N-V-R name of the latest tag and git_release would work with R part. Otherwise, they would be the same. It's not only that the names of parameters are different but also behavior is currently slightly different. With lead= of git_version macro, you can set it to empty string and it will cause that lead will be parsed from the latest package tag as part of V until the last dot. The thing after the last dot is then recognized as follow and it is the dynamic part that can be auto-incremented. If you, however, leave prefix empty for git_release, it will cause that the whole R part will be recognized as pivot. But the problem is that if release is multipart (i.e. it contains multiple dots), then the pivot will not be a number and cannot be auto-incremented. If, however, we inherit behavior from git_version for lead, then in case of multipart release, only the last part (after the last dot) would be recognized as pivot (or "follow" after renaming) and therefore auto-incrementing would work. In practice, it means that you can create several tags manually in the beginning, e.g.: git tag -a -m "alpha prerelease" pkg-1.0-f32.alpha git tag -a -m "beta prerelease" pkg-1.0-f32.beta (...this is only an artificial example, I know it does not conform to guidelines for doing prereleases...) and then create a final release tag: git tag -a -m "first release" pkg-1.0-f32.1 and since this moment use the auto-incrementing functionality (currently implemented by `rpkg tag`) because only "1" will be identified as pivot/follow, not the whole "f32.1" string. This example assumes you have the following in the spec file: Release: {{{ git_release }}} i.e. prefix is empty. If you used: Release: {{{ git_release prefix=f32 }}} or the new git_release_branched macro, it would work even now because prefix "f32" would be stripped from the part being auto-incremented. I would like to, however, optimize the git_release macro now so that I don't need to change it later anymore. That's why I am asking you for help. Could you, please, tell me: 1) if you see any problems with reusing the lead=, follow= scheme of git_version for git_release too 2) if you see anything else that should be done so that git_release can be used by packagers 3) anything else that is on your mind regarding this Thank you clime P.S. in case, you would like to see the current code (it can be quite hard to read if you don't do much bash): current code for git_version: https://pagure.io/rpkg-util/blob/60c7000101c0d885e6dad8b48f5b058e119ec7c7/f/macros/macros.d/git.bash#_418 current code for git_release: https://pagure.io/rpkg-util/blob/60c7000101c0d885e6dad8b48f5b058e119ec7c7/f/macros/macros.d/git.bash#_468 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
