On Tue, Mar 02, 2021 at 09:30:41PM +0100, Fabio Valentini wrote: > 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? The first time it can be done via the rpmautospect CLI command. > Will we need to "git pull" after every successful koji build so we get > consistent results between local checkout and infra build? After that, git pull/fetch is indeed the easiest method. > 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 :) The devil is in the details: pre-release, snapinfo, minorbump aren't really covered by distance being just an integer bumped. I know we considered the "number of commits since the last version bump" when we looked into this. I honestly do not remember precisely why we didn't go with it. Maybe Nils or Adam remember it? Pierre _______________________________________________ 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
