On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote: > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> > wrote: > > > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote: > > > But ... if it's not for different version streams, then what *is it* > > for? 🤔 > > > (What about the plans to offer different versions of e.g. NodeJS via > > > streams? Is that wrong then, too?) > > > > > > Being able to offer different versions is the only useful use-case I can > > > think of, and if that's not the intended usage ... I don't know why we > > need > > > it, or why somebody should use it at all ... > > > > Eh, I should probably butt out before I get things too far wrong. Let's > > wait for a licensed Modularity Person to show up and explain :) > > Stephen? Someone? > > > > Sorry, I've been on PTO. > > The idea behind a stream is that all updates within that stream are > intended to be fully backwards-compatible. In some cases (e.g. Node.js > major releases) this means that the version number is an appropriate way to > identify the stream. However, that's not always the case. Some projects > follow different versioning schemes and the version number is not actually > representative of the API stability (such as Cockpit, for example). > > So the stream naming is really dependent on what makes sense to the > upstream project. If upstream follows semver.org versioning (like Node.js), > then using the major version number as a stream is exactly right. For a > more complicated example, the IDM (aka FreeIPA) module in RHEL 8 chose to > use a stream called "DL-1" (domain level one). This is because it's a glue > project and a lot of its underlying pieces have differing version numbers, > but the whole stream is designed to support the ABI meeting a specification > they dubbed "DL-1". So any update, regardless of version bump, that retains > that compatibility is free to go into that stream. Well, the libgit streams wouldn't technically violate that, would they? That's sort of the point: they got in trouble by *following* that rule. When a new version came out that was API-incompatible, it showed up in a new stream. If it had been put in an existing stream and all the other streams had been rebuilt, things wouldn't have broken the way they did. 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? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
