This is the beginning of a living specification for how Ubuntu should present release upgrades. It is part of Ubuntu’s overall software handling.

  • Packages affected: release-upgrader

You should be able to invoke the upgrade process in any of three ways: from Software Updater, from Ubuntu Software Center, or from the Ubuntu installer.

Architecture notice

(bug 1845690)

If no new version is available for the installed architecture, an error should appear.


The text “If you reinstall Ubuntu from, future upgrades will be available.” should be present only if it is possible to install a still-supported architecture on this system.

Choosing “OK” should cancel the upgrade.

Invitation to upgrade

If you chose to upgrade from either Software Updater or Ubuntu Software Center, you should first see an “Upgrade to Ubuntu {new version}” dialog (bug 971958) containing information about the new version (bug 885720), the price of “Free”, and “Cancel” and “Upgrade Now” buttons.


Livepatch warning


If Livepatch is turned on, and you are upgrading to a version where Livepatch is not available, the dialog should morph to a confirmation alert: “Livepatch is not available for {new version}. If you continue, Livepatch will turn off.”


“Livepatch Settings…” should open System Settings to the Livepatch settings and should.

“Preparing to upgrade…”

While downloading package indexes and calculating the upgrade, Software Updater should show a progress window.

“Okay, here’s what is going to happen:”

Once the calculation has finished, the progress window should morph into a dialog summarizing what will happen (bug 874889).


In order:

  • “{size} will be downloaded.” — “That should take about {time}.”
    • The size should be rounded appropriately (e.g. “710 MB” or “1.2 GB”).
    • The time should be calculated based on how long the package indexes took to download (fixing bug 764836), and rounded appropriately (e.g. “about 13 minutes” or “about 1 hour 20 minutes”).

  • “Ubuntu will be upgraded to {version}.” — “That could take another hour or two.”
  • If any manually-installed software will conflict: “This software conflicts and must be removed:” (fixing bug 152077). The listbox should use the application’s icon and title if it is one, otherwise the generic package icon and the package name. The “I understand that this software will be removed” checkbox should be unchecked by default, and whenever it is present and unchecked, “Upgrade Now” should be insensitive.

  • “The upgrade will take up {size} more disk space.” — “You’ll have about {size} free afterwards.” (This statement is conservative, because some of the software installed may not go into /.)

  • “When everything’s done, Ubuntu should:”, with radio buttons for “Restart into {version}” (the default) and “Switch off the computer”.

Warning about applications that can’t be retained

If you have any graphical applications, or paid software of any sort, installed that must be removed during the upgrade, the upgrader should warn you using the icon and title of each item.



If you agree to go ahead with the upgrade, the dialog should morph back into a progress window. The progress bar should fill up only once for the entire upgrade, while the text below shows the current step: “Waiting for other software installations”, “Setting new software channels”, “Getting new software”, “Installing new software“, and “Restarting the computer”. Once the upgrade has passed the point of no return, the “Cancel” button should become insensitive.

Offering backup/recovery

(bug 876146)

We would like to maximize the proportion of people who can successfully use their computer after attempting an upgrade.

To do that, we would like to offer a simple backup or recovery system (probably not both) that lets people restore/recover from a failed upgrade.

This might involve:

  • inviting people to back up their system files to an external disk or USB key
  • installing a recovery partition on the same disk as is being used for the installation, and writing a minimal disk image there
  • changing the MBR so a specific key always starts from the recovery partition. (Ubuntu Recovery already does this for OEM installations.)

Previous work

Configuration file conflicts

If there is a configuration file conlict during an upgrade, the upgrade process should not ask if you want to replace it. Instead, it should rename the existing file to {filename}.{date}, and install the new file.

ReleaseUpgrades (last edited 2019-10-08 08:37:10 by mpt)