On Tue, Jun 25, 2019 at 8:45 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: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.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@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
_______________________________________________ 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
