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(a)pingoured.fr> 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(a)redhat.com>
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