Guide users to the desktop client release recommended by their connected server

### How to use GitHub

* Please use the 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) 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.

---

## Feature request

**Which Nextcloud Version are you currently using:** (see administration page)
Desktop: 34.0.2 and 4.0.10

Server: 33.0.6, as provided to us by as the Research Drive service by SURF, the IT cooperation for education and research organizations in the Netherlands.

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

_This issue bundles various related feature requests and are described from the viewpoint of a functional server admin._

For servers that enforce the Enterprise release channel in the client updater, both users with and without managed devices, as well as the organizations that own the server, could benefit from Nextcloud guiding these users to the Enterprise release channel client installer for new installs.

Currently server admins can configure the server to enforce the Enterprise release channel version in the updater, but there is no such guidance for new installs for users who’s devices are not provided with the client by default. Not on the website, not in the web interface (introduction pop-up or help page), nor when connected to Stable release client. Therefore, new installations may make use of newer, non-preferred (by the server admin) versions of the desktop client, such as the most recent Stable release channel version.

At least in education and research, non-managed devices include those of guest users, students without temporary employee accounts, students with temporary employee accounts but without managed devices, and employees who use personal non-managed devices (often macOS).

Organizations with device management could ensure that employees with managed devices are provided with the latest version of the Enterprise release channel through default or optional installations of the latest Enterprise release channel versions through their own software distribution systems, or through careful internally or publicly available instructions that link to the archive of installers or a self-hosted copy. Yet, in practice other versions may be used because the organizations may just refer to the newest release on nextcloud.com/install and does not manage the software (since a subset of users may use it, the admins involved in with specialized Nextcloud instance are not yet proficient in this method, or they lack knowledge of what version to use or how to track new releases). Plus, as mentioned, the web interface and the Nextcloud site only refer to the stable release (with community support) and employees may be allowed to install software (the Stable release client) that is not distributed by their organization.

In theory, all types of users could be carefully guided to the installer of the Enterprise release channel version through public documentation, but users may choose to only interact with the web interface after an invitation or auto-provisioned login, after which they may visit the nextcloud.com/install page (with only the newest Stable release available) or they visit this page after seeing the introductory pop-up or the help page.

This lack of guidance may cause that not all users of a server that forces the Enterprise release channel on the desktop updater use this Enterprise channel release and they may experience more, other and newer problems than the majority of the server's users that use the Enterprise release channel client (either through managed software, instructions or by a past installation of the Stable client and having updates suspended until this release becomes the Enterprise version and the version number is superseded). Organization admins may not be aware of the newer problems, and they may not know a solution (although following and searching the GitHub repository would help). Recent examples in v4 and v33 are: ghost folders (8915), dysfunctional updaters (9347), silent data sync failure (9945). While updates with critical bugs are retracted from the client updater server, there is no rollback for non-managed devices, although a critical message feature has been [requested](https://github.com/nextcloud/desktop/issues/9543). Also, updates sometimes remain published on the nextcloud.com/install page while already retracted from the updater service, thereby extending the period during which new problematic installs without communication to the user occur. The server admin could communicate issues to the users, but the issue may not be relevant to all, so users would have to check their version number before reading the message (not a solution, but a reminder to use the Enterprise channel release version). The server admin could limit the max supported version to the latest Enterprise channel release, but I imagine this would cause issues with installs of the Stable release client. There would be a warning, but the user experience of needing to downgrade without a warning before the original install would not be optimal. Users would have to choose or test which file type is needed for installation, although file size would be a clear indicator.

Even if optimal instructions and communication could get most of the userbase on the preferred version, it could still save certain organizations (such as those in higher education and research) the considerable effort of organizing this if users with non-managed devices are guided to the Enterprise release channel client installer, especially small to medium-size organizations with smaller scale benefits.

**Describe the solution you'd like**
Guide users to desktop client release recommended by their connected server in several ways:

**-1. A new desktop client changelog site page, similar to server**

Develop a new changelog page for the desktop client similar to Nextcloud server’s https://nextcloud.com/changelog/, with:

- Major release headings with incremental versions listed below each heading.
- Each listed version has: date, installers, changelog, and importantly an anchor link (for point 2, 3 and 4.).
- Above the list of versions: ‘Go directly to the latest version of:’ with big buttons for the both Stable update channel and the Enterprise update channel. These buttons link to latestFilesStable or latestFilesEnterprise version, which is configured to automatically refer to the latest versions of the major releases that are provided by the Stable and Enterprise update channels and designate those versions as such with a badge/label.
- On the very top: a new query tool for server preferred update channel or specific version, described in 2.

Link to this page on https://nextcloud.com/install/#desktop-files instead of providing the latest Stable release version.

Keep versions listed that are at least as old as the first version of the current Enterprise channel major release version or versions of a certain time range that would still include the first version of the current Enterprise channel major release. If possible, when a previously listed version not found by its prior anchor link, show a banner with ‘version X is not listed anymore, try https://download.nextcloud.com/desktop/releases/, where this version may still be found.

**- 2. A server query tool for server preferred client on top of the new desktop changelog site page**

Add a prominently visible server query tool to the top of the new desktop client changelog page. You should be able to fill in the server address, query the server for a publicly presented description of the configuration for “Enterprise release channel client update enforcement” (optionally extended with the configuration of enforcement of older incremental versions of these or other major releases). In result, the advised installer anchor link shown.

I imagine the filled in server address should not be processed by Nextcloud itself to prevent merger of this data with other collected data (regardless of its usage), so, if possible, code should run locally in connection with the queried server. If that is not possible, point 4 could be even more important for guiding users that installed a non-preferred client visiting the Nextcloud site in an unguided manner.

**- 3. Guidance to the desktop changelog page or to preferred release channel or version anchor links via the web interface introduction pop-up and the help page**

Through both the introduction pop-up for new users and the help page, refer to either the new changelog page or the anchor link for the latest version of the server preferred desktop client update channel (or optionally extended with the configuration option of a specific server preferred version).

If mid-page referral via an anchor link for the latest version of an update channel (or for a specific version) confuses the user (who may then scroll back up for the latest Stable version), show a banner saying this is the server preferred version. Or, as described by one of the two options above, just link to the new changelog page (1.) with on top the query tool (2.), which should guide to the server preferred version.

**- 4. Guidance via new client updater rollback, new critical message feature or via integration in existing min./ max. supported version warnings.**

Possibly more complex, but important when point 2 is not possible.

When the server forces the Enterprise update channel on the updater, and it is recognized that a newer version has been installed, provide a rollback option (via a version anchor link, installer link, or background downloaded installer execution button). The server (possibly on an old server release) would need to query an online service for the most recent client Enterprise update channel version. There could be an ignore option to not adjust to the advised version since one person may be connected to multiple servers with different update channels and have a preference not to comply, they may require a specific fix or functionality from the newest major release, or they want to test the newer releases.

If rollback functionality takes too much effort to develop, and a critical message feature is already to be developed, then use the [requested critical message feature](https://github.com/nextcloud/desktop/issues/9543) to provide a anchor link for the latest version of the server preferred update channel (or a specific server preferred version) or to the new desktop client changelog page where the user can enter server address(es) to find the version preferred by the connected server(s).

Alternatively, integrate such communication via the client itself through the existing minimum.supported.desktop.version and maximum.supported.desktop.version feature, not by blocking connection, but solely by warning (and possibly linking a version) in a similar method with the update channel configuration detection or new preferred channel/version configuration fields.

**Describe alternatives you've considered**

- Alt1. Just separate Stable and Enterprise client update channel install pages (instead of point 1) that allow for guidance through a server query tool (point 2, but then on nextcloud.com/install or a general client (install) page), configurable buttons in he introduction pop-up and help page of the web interface (point 3), the client (in various ways, point 4), and links in the organization’s server documentation. A simpler website experience, but the more complex and flexible (with server preference for any specific version) client changelog page would be more similar to the existing server changelog page.

- Alt2. Just point 4 with any type of guidance to the latest Enterprise client update channel version, but re-installation of a different version without any prior guidance may not provide a good user experience.

- Alt3. You could also build the query tool into the installer. The user could then enter all addresses they want to use and be advised the correct version to install, but then the installer would have to be able to install both most recent versions of the client to not have to download another installer, which would complicate releases, unless there is one generic installer, which pulls in required files. But they may start using servers with with another preference in line with more critical files and they would still benefit from point 4.

- Alt4. Further development of concise, server specific instructions for all relevant types of users shared through a package or a public page. The public page link can be configured to be included in the invitation mail, the account creation page, the help page and more, at least with the service provided to us by SURF through Research Drive. But this documentation requires equal effort for all servers (incl. servers of small organizations). Plus, when account auto-provisioning is applied (in our server for employees and all students, not guest accounts), users are not guided to the documentation through links in invitation mails and on account creation pages. The focus of the here described types of users is only on the client when they are actively searching an installing the client. At this point they may be past invitations, account creation and introduction pop-ups and they may visit nextcloud.com/install without reading our documentation (which is still findable via the help page). At this point there is no active guidance to the advised installer for these new users (or old users with new devices) and when the newest major release is installed there is no reminder that the Enterprise channel release is the server preferred release.

**Additional context**
You could make the argument that the described theoretical or experienced problems are due to insufficient quality control of the Stable release, or some remaining quality control gaps for non-resolved pre- and post-pullback installs due to:

-the lack of a critical message feature (non-resolved pre-pullback install) or the lack of a suggested client version rollback feature (non-resolved pre-pullback install)

-the (occasional) lack of timely removal of versions from the install page after already being pulled back from the update server. (non-resolved post-pullback install).

Communicating version issues as a server admin is not cost-effective, may come too late and is dependent on staying aware of issue (sometimes caught by a service provider, if applicable).

You could also make the argument that if the wider community would increasingly test (certain aspects of) new client versions, that the Stable client would be more stable. But the here mentioned types of users are not potential testers and in the current situation I believe the implementation of point 1 to 4 or alternatives could improve Nextcloud implementation for education and research, for small and medium-size organizations, and for Enterprise use in general.