On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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>
The first option aligns with our current guidelines suggesting that
such bumps go at the end after the DistTag. I personally have felt
those were ugly, but there you go. The second option is actually what
I use at $DAYJOB for our environment, and I've been pretty pleased
with how that works in practice (our buildsystem builds for all target
distros from the same commit at once, so the EVRs are rather strictly
matched). However, it might not be workable with the whole "Koji and
manual build per target" thing. The third option is how openSUSE Leap
is currently done, primarily to make Leap packages lower than SUSE
Linux Enterprise packages (openSUSE Leap can "upgrade" to SLE). I'm
not a fan of this scheme as it feels rather "weird" to me.
Naturally, there is also an option that would involve enhancing RPM:
extending EVR comparisons to factor in the DistTag as a formal
property (e.g. EVRD). ALT Linux recently started doing this. I will
admit there is some appeal to this, as it makes the distro versioning
aspect a property unto itself. This would require making Koji move
from NVR to NVRD for its uniqueness constraint, which would be an
"interesting" change to implement. This would eliminate the %dist
macro entirely, and remove boilerplate entirely from the Release
field. This would make all the questions and games about sequencing
the values in the Release field to be completely about the unique
build versioning of the package. In practice, I think this is just a
fancier variant of option two above.
>
> Another question regarding the release field is: how would we deal with
> pre-releases and other unsortable versions?
> The current doc relies on <extraver> etc. in the release field as per:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_unsortable_versions
> Would using the tilde to specify pre-releases in the version field be sufficient
> (as described in
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde)?
> I.e., how can we cater for snapshot releases (e.g. based off a specific git
> commit)?
>
Pre-releases can use tilde versioning, and starting with Fedora 31, we
can also use carat versions for post-releases.
Carat versioning draft from tibbs from long ago:
https://fedoraproject.org/wiki/User:Tibbs/TildeCaretVersioning
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
