I thought about this for a while, and I can see some conceptual similarities between upgrading a major Fedora release and changing a module stream. I tried to think about major Fedora releases (I mean f28, f29, etc) as "streams" of Fedora, the same way as streams of modules, with stable API.

Until now, there was a single type of upgrade in Fedora — the major release upgrade. But with Modularity, there is more than that. It's no longer single monolithic upgrade of the whole OS. People can now upgrade (== change streams) different parts of the OS potentially independently. We need to think how to present this to users. Will it require a change of mindset?

Also, with the effort of separating apps and the OS we've discussed at Flock, will the goal be to get the "OS part" upgradable at any time, and, independently on that, users will choose to upgrade (again, change streams) individual parts of the system (modules) for new features? That probably will require a change of mindset. It sounds similar how a phone works. Do we need to develop a whole new UX around this?

On Thu, Sep 20, 2018 at 11:01 PM Randy Barlow <bowlofeggs@fedoraproject.org> wrote:
On 9/20/18 1:56 PM, Matthew Miller wrote:
> If it's "they'll find out when dnf system-upgrade errors out!", then see
> above. I'm ... not enthused. Something in dnf system-upgrade needs to do it;
> possibly a "dnf system-upgrade prep" step before "download".

I agree. Would it be feasible for the system-upgrade plugin to prompt
the user with "hey, you are using 1.7 but you need to switch to 1.8 to
upgrade. Proceed? (y/N)".

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--

Adam Šamalík
---------------------------
Software Engineer
Red Hat