On 2019-06-25, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > So I'm still not confident about the story here. Let's take something > that does follow semver: it's not going to change API compatibility as > *often* as libgit2, but ultimately it's gonna happen. And in Rawhide, > presumably, when a new major version comes out, we want installs to > move to that new major version; that's how we've always done things in > the past, that's what Rawhide is for. > > So what's the story there? How is that supposed to work? We had had "master" streams that were deprecated. They lived in "master" dist-git branch and were supposed to contain the latest available version regardless of ABI changes. Mainly for integration and distribution-development purposes. It was meant in the same meaning as what "Rawhide" means for Fedora releases. The issue with master streams was that there was no platform:master and thus they leaked into released distribution. Either when branching a new a distribution from Rawhide or when using a stream expansion. But I believe we need something like that. Otherwise how are we supposed to develop modules in Rawhide? A developer story: I created perl:5.30 stream that is the latest Perl version now. It consists of many RPM packages. Some of them will get a new upstream release between creating perl:5.30 stream and branching F31 from Rawhide. And some of them will break API. What are we going to do with these new package releases? Should we ignor them, not integrating them, until a new perl:5.32 is created next year? Or should we add them into perl:5.30 and risking the ABI change? Don't forget I want to provide the stream to other Fedoras. One feasible way is submit perl:5.30 to testing for released Fedoras, but postpone pushing to stable until F31 is branched off. That effectively makes perl:5.30 in-developement until the branching. Is that an accaptable way of developing modules? The drawback is we align stream life cycle to Fedora releases. Another approach would be to build perl:5.30 only for Rawhide (platform:f31 now) and forbid relengs to tag it into F31 composes on branching. But this manual process would be error-prone would not scale. We would need some way of marking a stream as a Rawhide only. And not only for relengs. There is the issue of modular dependencies. It's not feasible for packagers to update the modular dependency every time a new dependency stream emerges. Or is it? Do we need a "master" streams for building modules? I hope I missed somthing and there is an obvious and easy way of solving this issue. Otherwise the modularity is not sustainable for developers. -- Petr _______________________________________________ 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
