On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson <adamw...@fedoraproject.org> wrote:
> On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote: > > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson < > adamw...@fedoraproject.org> > > 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. > Right, this was information I was missing a week ago. I think libgit2's usage of the module streams here is *correct*, except for the part where they're trying to change the default in a released Fedora, which is in violation of the stable updates policy. > > 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 have an open RFE for DNF to support recognizing a change in default streams and switching over. It is complicated and we're still working out the details. Please stay tuned. (Sorry, I can't find the BZ offhand, but hopefully someone else can chime in with it).
_______________________________________________ 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
