Hey Petr!
On Mon, 2020-01-13 at 10:34 +0100, Petr Pisar wrote:
> (2) The new values must be larger than all historical values (across
> all historical Fedora releases). That assures than a new build won't
> become obsoleted because of a decreased release.
can you clarify what you mean with "historical values/releases" here?
Would it include all currently active releases at some point in time
(i.e. everything up to F32/rawhide ATM)?
The way I see it, we should have a differently phrased requirement,
ensuring that within an upstream version of a package, the release of a
build in a higher Fedora release should be "newer" than of any previous
build (for the same version) in an older release.
I mean that we e.g. can't cater for the case where a package is built
in an older Fedora release, but no correspondent build is done in a
newer one, just as without automation: if a package has say releases
-1.fc30, -1.fc31 and -1.fc32 and then the packager only bumps to
-2.fc30 and builds in F-30, there's not much we can do about it (other
than chiding them for it ;)).
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
_______________________________________________
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
