On Mon, Oct 07, 2019 at 04:34:21PM -0400, Matthew Miller wrote: > On Mon, Oct 07, 2019 at 08:13:17PM +0200, Fabio Valentini wrote: > > To quote you from the other ongoing thread: "The default stream for a > > package shouldn't be updated in disruptive ways in shipped releases" > > If that's the case, then what *is* the benefit of abandoning the > > non-modular version of packages, if default streams need to basically > > be maintained separately for different branches anyway? 🤔 > > 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. IIUC, Modules make this particular problem worse: Let's consider this: a new version of ook came out a month ago, got released in F31, and it seems nice and stable and fully backwards compatible. The maintainer decides it's time to push it out to stable releases. - non-modular: git checkout f30 && git merge f31 && fedpkg build && fedpkg update (OK, consider this pseudo-code) - modular: the "stable" stream gets updated, and now F29 users get an update just before the release is to be retired. This is at best a waste of compilation cycles and download bits, and increases chances of breakage in a release that is supposed to have a minimum of disruptions. The obvious solution is to *not* update in F29, which means that as Fabio wrote, > default streams need to basically be maintained separately for different branches Zbyszek _______________________________________________ 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