So I was thinking about it and the unification of code for git_release
and git_version makes sense according to my best knowledge.
Below is my reasoning. It would be great if somebody could check if it
is correct.
Note that in the end, the macros should be easy and intuitive to use.
The explanation below should only show that they are also robust
enough to cover all the possible use-cases with the assumption that
backward-compatible changes (i.e. adding more features/params) are OK
to make.
-------------
The only use-case which won't be covered by the provided lead/follow
functionality for the git_release (and git_version) macro is if one
would maintain two (or more) tag sets in a single branch.
E.g. in a single branch (called e.g. master), there would be tags:
prunerepo-1.14-1
prunerepo-1.14-2
prunerepo-1.14-master.1
prunerepo-1.14-master.2
One can work with just a single set when using git_release or
git_version macro. That's pretty much a physical limitation of each
macro. But one might want to be able to at least pick a set to work
with.
Now, this is currently a problem with the lead/follow scheme if the
set we want to pick is the one with the tags:
prunerepo-1.14-1
prunerepo-1.14-2
i.e. the "unprefixed release" variant.
We could try to use {{{ git_release lead="" }}} (i.e. just specify
lead should be empty, which is the default anyway) and hope this will
filter out the tags:
prunerepo-1.14-master.1
prunerepo-1.14-master.2
because follow is always the last component so everything before that
needs to be lead and we specified that lead should be empty, right?
Well, it doesn't currently work like that. Tag filtering that uses
lead will search for all tags, the release of which is literally
prefixed with ${lead}.
So if ${lead} is empty, all the tags from both sets will be matched so
we will recognize the last created one as our "latest tag" from which
release is derived. I.e. the resulting release string will be
alternating between values from {1, 2} and {master.1, master.2} based
on which tag (from which set) is currently the latest one.
While here it's a "bug" (or rather, I think, an unsupported use-case),
it's a feature in another context.
While the behavior doesn't allow for maintaining multiple tag sets
within a single branch (which should be rare imho) while picking the
desired one for version/release generation, it allows for direct
release/version derivation from the latest tag no matter what was the
lead in the latest tag.
I.e. if have this in my spec file:
Release: {{{ git_release }}}
(side note: in fact, the recommended form to use is git_dir_release)
...I can create whatever tag in the current branch, e.g.:
prunerepo-1.14-this_is_really_cool_package_pls_install.1
and when that spec file of mine is evaluated, I get:
Release: this_is_really_cool_package_pls_install.1
Another example: if the tag is:
prunerepo-1.14-42
I get:
Release: 42
I.e. no matter what the tag is, it will match and will be used for
generating the release field. In addition, if the last component of
the release is a number, auto-bumping will work as well.
I find this more pleasant and less constraining behavior. It allows
for setting up an initial tag with an arbitrary lead, which will be
then used for automatic bumping (given that follow is a number) and
the lead will be automatically carried over to the new tags.
If, however, at some point somebody needs the strict interpretation of
lead, an additional parameter of git_release/git_version can be
provided to enable it.
So the macros should be sufficiently robust after the behavior unification.
clime
clime
_______________________________________________
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
