Neal Gompa <ngompa13(a)gmail.com> writes:
On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
>
> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
> > >
> > >
> > > The release field would need to be set by koji ignoring whatever is in the
spec
> > > file. How do we want to do this?
> > > - Based on dates?
> > > - Using an always increasing integer?
> > > - Using the number of successful builds since the last time the version
field changed?
> > > - Another idea?
> > >
> > > The third option looks like to be the one closest to our current behavior.
> > >
> >
> > I always envisioned that we'd use a variant of the third option.
> >
> > The options I've thought of:
> >
> > * <commit-at-version>%{dist}.<build-at-version>
> > * <commit-at-version>.<build-at-version>%{?dist}
> > * %{dist}.<commit-at-version>.<build-at-version>
>
> I've been thinking a bit about this and been wondering any reason why not to do
> simply?
> <build-at-version>%{dist}
>
> This would basically mimic what we are currently doing by hand, it would be the
> less changes to our current way of working (making opting-in smoother).
>
If we're not doing automatic builds, sure. I've been going on two big
assumptions:
1. We're going to do automatic building
2. We need *some* kind of stable leading portion of release for
packagers to use for specified dependencies, especially
Obsoletes+Provides combos.
How is openSUSE taking care of 2 then? OBS bumps the release on each
rebuild and that can result in crazily high release numbers. I assume
they got a mechanism for Obsoletes+Provides and we could use that too?