In yumrepoinfo.conf we currently have this:
yumrepoinfo.conf
# true for "top" repos corresponding to currently supported Fedora releases supported = no
and this
# Fedora 21 [f21] url = %(rawhideurl)s path = development/21 supported = yes
(after D192 is pushed). It is a bit vague what 'supported release' is, but people would probably generally assume it means 'stable release'. In this case, supported should be no for F21, since F21 is Branched, not a stable release. But in upgradepath, we have this code:
supported
no
# discard EOL releases and Rawhide if not tag in self.repoinfo.releases(): return None
(where releases() return everything with supported = yes).
releases()
supported = yes
So upgradepath considers supported to be a bit different, even branched release should be included.
To fix this inconsistency, I think we should give a way to distinguish: a) EOL release b) stable release c) branched release d) rawhide
The easiest way seems to me to be replacing supported with something like status (or release_status) with possible values: EOL, stable, branched and rawhide.
status
release_status
EOL
stable
branched
rawhide
With this, yumrepoinfo.releases() would only return stable releases, and there would be new methods for accessing branched and rawhide releases. Upgradepath could then do something like this:
yumrepoinfo.releases()
# discard EOL releases and Rawhide if not tag in self.repoinfo.releases() + self.repoinfo.branched(): return None
This ticket is a duplicate of https://pagure.io/taskotron/task-upgradepath/issue/3
This ticket had assigned some Differential requests: D194
Login to comment on this ticket.