On Tue, Feb 16, 2021 at 8:20 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>
> On Tue, Feb 16, 2021 at 03:38:35PM +0100, Fabio Valentini wrote:
> > On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
> > >
> > > On 16. 02. 21 14:48, Fabio Valentini wrote:
> > > > if version_at(commit) != last_version:
> > > > return 0
> > >
> > > Should this be "return 1"?
> >
> > No, 0 is correct. If the version does not match, this is the last
> > commit *before* a version update.
> > The "max(parents) + 1" then sets the Release to 1 for the commit that
> > actually changed the version :)
> >
> > > To prevent accidental divergence between the git history and the build system.
> > > That's why this information is only used in the koji plugin, locally (ie: via
> > > the rpmautospec CLI) it only relies on the git tags.
> >
> > So ... you want to *prevent* divergence by *introducing* divergence? I
> > do not follow ...
>
> The build information is used to check if all the builds made in koji exists as
> tags. If they don't, then they are added, thus resolving the divergence.
> If they do, git tags are used, just like they are used locally.
There's another issue that I see with using both git tags and koji
build history:
How do users get those tags into their local repository clones, if
they are created by koji after successful builds?
Will we need to "git pull" after every successful koji build so we get
consistent results between local checkout and infra build?
Side note: This amended algorithm should always produce incrementing
release numbers, even across branches:
def release_num(commit, last_version) -> int:
if version_at(commit) != last_version:
return 0
else:
distance = max(release_num(parent, last_version) for parent of commit))
if is_merge_commit(commit):
return distance
else:
return distance + 1
That should solve both the upgrade path issue and the data source
problem. No need to look at either git tags or koji build history :)
Fabio
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
