Improving the update experience [web]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

TLDR

Core problem: The main update screen (in the web UI) lacks information needed for the highest likelihood of a successful update experience - with a minimum of surprises - each and every time.

Solution: Make the options / info presented in the update screen more consistent, helpful, and likely to result in a successful update experience.

e.g.

• Distinguish major version updates from minor/patch version updates when offering to update
• Make it clear when the in-use major version has not reached end-of-life but merely doesn't have another minor/patch update available at the moment (right now we immediately just present the next major version update as the update path - if one happens to be available - but without this context)
• Present the same update options regardless of when an admin happens to load the update screen and where we are in our release cycles as long as the currently in-use release has not reached end-of-life
• Arm admins with the information necessary to pull off a successful update in their environment so that they don't update to a new major version without realizing there are breaking changes they need to accommodate for in their environment
• Ideally, present all the update paths available to an admin at any given point in time

Is your feature request related to a problem? Please describe.

I'm always frustrated when I see Nextcloud system administrators:

• running fully up-to-date and supported versions (e.g. 27.1.6) update to a major version because it's proposed in the Update screen, without realizing the availability of a newer major release doesn't necessarily imply their current v27.1.6 is out of date or won't be receiving any further updates (in this example: they wouldn't even be offered a v28 release if v27.1.7 happened to be released just before they load the Update screen)
• unwittingly install major version updates of server without realizing they may need to make adjustments to their local environment for the update to function properly
• don't realize that the project puts time and effort in maintaining 2-3 major releases simultaneously so that everyone can make their own choices about how aggressively/conservatively to adapt major versions in their local environment

e.g. when v29.0.0 is released, on 2024-04-24, all current users of v28.0.5 (or thereabouts) will be blindly offered the update to v29.0.0 as if it is the next natural update step for all environments even though v28 is not end-of-life and some may wish to stay on v28 a bit longer. Or, others may prefer to update to v29.0.0, but they need to be made aware of the breaking changes that may require accommodation in their local environment to have a successful update experience.

The goal isn't to direct people one way or another, but to let them decide and give them what they need to make an informed decision and have the highest likelihood of a positive update experience.

This is ultra confusing for new users, but even long time users aren't sure what the next update step is sometimes (at a minimum they have t to always look up the necessary context elsewhere). Yes, we have docs and the wiki page, but one would naturally expect the updater itself to be intelligent about what it presents as the options. Plus we don't even link to those docs or the wiki on the update screen (the release channels link which is included isn't helpful on its own since all actively maintained major releases are offered in the Stable channel).

The above combine to create an inconsistent update experience that isn't driven by the facts, varies depending on timing (regardless of an existing installation's ongoing maintenance/support status), and doesn't present critical information needed before deciding to upgrade to a new major version.

It's critical we inform admins before they make major version updates, since there are often breaking changes that they need to adapt to in their environment (e.g. web server configurations, changes in Nextcloud behavior).

Describe the solution you'd like

I think we can:

• more clearly distinguish in the Update screen that the available update being is a major update, and it's not a requirement that it be updated to in order to continue to receive bug fixes and security updates (unless, of course, the major version in-use has also reached end of life).
• provide a direct link to the Critical Changes section in the documentation for any major version updates offered
• include either an excerpt or link to the Maintenance and release schedule section of the docs
• provide a link (or even an excerpt from) the Currently maintained versions page

Therefore:

• we should present additional information
• adjust how we present update options

This will be both a mixture of language and visual presentation. It may require a few incremental adjustments to get it right.

Describe alternatives you've considered

• documentation
• telling people over and over
• adjusting our release channels to something like: latest, stable, oldstable (e.g. based on current majors that would be v28/latest, v27/stable, v26/oldstable) while still adding context links to Critical Changes/etc to the update page

Additional context

This is how things currently look when one is already running the latest supported v27.1.6 (but it will change yet again when v27.1.7 is released; no longer offering a v28 release to update to):

If a v27.1.7 happen to be available I wouldn't even be offered a v28 update so what's shown is inconsistent and driven by what releases just happen to be available at the time someone looks. For example:

We could possibly also provide other clues (sticking to facts to let them decide) like:

• "x days of bug fixes remain for this major version" or "end of life is schedule for m/d/y, but bug/security fixes will continue to be provided as long as you keep the patch/minor level up-to-date"

To make things more consistent and less dependent on our release cycle, we might also want to consider offering a list of any relevant update path available to them at any given point in time - e.g.

You're on v27.1.5 and a new minor version is available which fixes critical bugs: v27.1.6
- This release is still supported and receives critical bug fixes and security patches.
- End of life is planned for m/d/y
- Please keep up with minor patch levels to keep your Nextcloud secured and free of known bugs
- You may also update to *major* version v28, which was realized x days ago, but please review the Critical Changes before doing so and also assess whether your environment is prepared for other elements that change in between major releases (e.g. user interface, supported apps, etc.). 
- There is no need to update to a new major version until the one you're running reaches end-of-life, but you may wish to do so for new features/functionality.

Start at the main update screen in the web UI and trace how current update options and release information are assembled. Done means clearly distinguishing minor and major updates, presenting supported-version and end-of-life context, and linking to critical changes and maintenance schedule information.