Broken from the "Summary of Reddit thread".
Fedora's lack of a graphical major-version updater comes up
constantly. I think it's probably time to start brainstorming how to
solve it, with a stated intention of having things work for upgrading
Fedora 23 -> Fedora 24 *at minimum* and an ideal situation of having
Fedora 22 -> Fedora 23 upgrades work (with changes made during Fedora
22's stable lifecycle to support this).
So to brainstorm, I'll start with a list (in no particular order) of
things I think we want as goals (not necessary technical goals but
user experience goals) and then go into a few known technical
enhancements that need to be accomplished to get there. (Note: many of
the experience goals may already be possible with some combination of
GNOME Software and/or fedup, but they are included for completeness).
Much discussion welcome!
p.s. I am not a member of the Workstation WG, but I am a highly-
interested party.
== User Experience Goals ==
* The user must be informed that a major-version upgrade is available
soon[1] after it is released in a manner that is consistent with the
integrated operation of the system.
* The user must have the option to "snooze" this notification for a
sensible amount of time (or permanently) to avoid nag.
* The mechanism must be capable of informing the user of how much
disk space will be required to perform the update prior to their
initiating one.
* The upgrade mechanism must *not* download any files other than
metadata prior to a user request for upgrading.
* The upgrade mechanism, once requested, must download all packages
to be upgraded locally before starting (to avoid network issues in the
middle of the upgrade process).
* The distribution upgrade mechanism *must* take place in a dedicated
upgrade environment with no other services running.
* The updater must be capable of first updating *itself* to the
latest stable version prior to attempting an upgrade. This *may* also
require updating all packages on the local system to their latest
versions, if needed.
* The resultant state of the machine after an upgrade should be
equivalent[1] to a freshly-installed system of the new version,
configured the same way as the previous version.
* Once the system has entered the dedicated environment, the updater
should[2] complete successfully or else make no changes to the
installed system, when only Fedora repositories are enabled.
* The update notification should be configurable to support upgrades
to Alpha and Beta releases, if desired.
== Non-goals ==
* It is not a requirement to be able to downgrade from a successful
distribution upgrade.
== Technical implementation thoughts ==
* For Fedora Workstation, the obvious graphical front-end should be
GNOME Software
* ... However, the low-level should be implemented by PackageKit so
that other DEs can implement their own solutions.
* The fedup tool already provides a non-graphical implementation of
the dedicated upgrade environment (as well as some odds-and-ends for
managing changes that aren't handled by simple package upgrade
scripts). This logic should be moved to PackageKit and maintained
there, with fedup becoming a CLI client implementation of it.
* The Fedora infrastructure would need to add new metadata to
describe releases (also supporting Alpha and Beta releases) that the
upgrade mechanisms may query for. Mirror-manager is probably a good
place for this.
* From a user perspective, GNOME software should provide AppStream
metadata for a Fedora N+1 package, which would have special properties
of enabling the distribution-upgrade. (Modeled somewhat after OSX
upgrades which are done by "purchasing" the new version in their OSX
app store)
* When the user receives a notification for a distribution upgrade,
clicking on that notification should bring them to the upgrade entry
in GNOME Software (or other tool as appropriate to other spins).
[1] Definition malleable.
[2] I hate the word "should", but I don't want *every* edge case as a
bug here.