On 10/7/19 4:34 PM, Matthew Miller wrote:
To me, most packages would benefit from having two streams: fast and slow.
That's the essential problem I want solved anyway. (Maybe with CentOS
Streams: fast, slow, very slow.)
The "slow" version would be updated on a careful cadence with big updates
aligned with release boundaries. The fast version would be rolling latest.
And for applications, you can pick which you want.
That sounds very reasonable from the user point of view. I think the
burden on maintainers would then be to decide which path each release
belongs in--I guess the rules would be similar to those for API bumps.
Having said that, I am not sure it will solve the problem with
ecosystems requiring specific collection of component versions (*): what
is the expected number of required versions for each module in those
environments? If it is much more than 2 then fast/slow scheme might not
work.
I tried to get a handle on this by counting the available versions in
the Fedora Modular repos:
yum module list --releasever=30 --disable-repo
updates-modular,update,fedora | cut -d' ' -f1 | sort | uniq -c | colrm 9
| sort | uniq -c
and there seem to be 33 modules with one version, 9 modules with 2
versions, 5 modules with 3 versions and 2 modules with four versions
(avocado, dwm and postgresql), with similar results for F29 and rawhide.
(*) Java, Ruby, npm, maybe even Python
(**) I am not sure if this is the way to get a comprehensive list of all
modules---there's fewer modules than I thought, and too many one-version
modules; please suggest a better way.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
