On Tue, Jun 25, 2019 at 8:45 PM Stephen Gallagher <sgall...@redhat.com> wrote:
> > > 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. > We are NOT changing default version of libgit2. We are changing dependency of some other tools to use new version of libgit2. >> 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 >
_______________________________________________ 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
