On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson <adamwill@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.