On Sat, Oct 05, 2019 at 02:35:59AM +0200, Kevin Kofler wrote: > There are many possible reasons for shipping the same upstream release > across different Fedora releases:
[...snip good list of reasons...] > That said, I am not a fan of the Updates Policy as written because it is > written in the form "do not push new feature releases as updates unless X, > Y or Z", whereas I think it should be "do push new feature releases as > updates unless X', Y' or Z'". Still, I think we all agree that some > feature releases just need to go out (e.g., because they include security > fixes that are impractical to backport) whereas some definitely must never > go out as updates (e.g., anything that breaks user configuration). I agree on this too. A key goal of the modularity project is to allow some of the cases to be better addressed by allowing packagers to think in terms of upstream changes which affect user experience separate from the Fedora release cycle. The default stream for a package shouldn't be updated in disruptive ways in shipped releases, but a new-version stream could _also_ be available. And at the same time, if you upgrade to a new Fedora OS release but still need the old behavior and the packager is still maintaining it, you should be able to opt in to it. Now, whether it's delivered that perfectly yet is a matter of ... well, we know it hasn't and there's more work to get there, especially in terms of packager experience. But I think it's a good idea and something ultimately we will get to. -- Matthew Miller <mat...@fedoraproject.org> Fedora Project Leader _______________________________________________ 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
