Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] consider pinning the minimum.supported.desktop.version at every release #49519

Open
skjnldsv opened this issue Nov 27, 2024 · 7 comments
Open

Comments

@skjnldsv
Copy link
Member

On server, we have a config named minimum.supported.desktop.version
It block the clients from syncing with Nextcloud if they're too old.

Current is set to 2.3.0 which haven't changed in 2 years and point to a release from.......2017 😱

Suggestion

  • On each (major?) release, we adjust the default value here and here. We could set it to something like the current minor version at the time of release
  • We add a setup warning when the configured minimum.supported.desktop.version is set to something older than xx months
@skjnldsv
Copy link
Member Author

cc @nextcloud/desktop @tobiasKaminsky @sorbaugh @AndyScherzinger

@solracsf
Copy link
Member

solracsf commented Nov 27, 2024

Yet I agree that 2.3.0 is quite old, problem is that some old OS distributions would not support them.
Example between 3.13 and 3.14.

https://docs.nextcloud.com/desktop/3.13/installing.html#system-requirements
https://docs.nextcloud.com/desktop/3.14/installing.html#system-requirements (32bits support is dropped, yet, server supports it).

But having something like 3.10.0 now (to drop at least very very old clients) could be an option IMO.

We add a setup warning when the configured minimum.supported.desktop.version is set to something older than xx months

I vote on this perhaps.

@solracsf
Copy link
Member

solracsf commented Nov 27, 2024

Another hint: instead chnaging those values often, desktop should follow a EOL policy similar to server, let's say, support the latest 3 majors.
https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule (and have a page like this too).

Once the support for one major is dropped, then a server setup warning should warn the user about this and the admin could bump version after he consults system requirements and decides it's environment will support it.

Actually, I couldn't find any information about which versions of Desktop are supported or not, and this is a problem.

Similarly, there is no option to pin to a "minor" version on desktop; stable (default) channel will always update to the latest "major" (from 3.14.3 to 3.15.0 for example) exactly because there is no maintenance policy and user can't pin to minor relases only (conservative updates) leading to major problems sometimes.

Only option to have a conservative updates policy user-side is... disable automatic updates (enabled by default).

@PhilippSchlesinger
Copy link

Similarly, there is no option to pin to a "minor" version on desktop; stable (default) channel will always update to the latest "major" (from 3.14.3 to 3.15.0 for example) exactly because there is no maintenance policy and user can't pin to minor relases only (conservative updates) leading to major problems sometimes.

@solracsf
See nextcloud/desktop#7382 for a feature request similar to what you describe.

@AndyScherzinger
Copy link
Member

Clients, mobile and desktop, support a 5 year range, so clients drop Server support after server version is 5 years old. This is done to ensure we can always maintain a single client version going forward.

I would also suggest to rather have a server warning if the set value is below a version we believe should be used (mostly due to disclosed vulnerabilities).
Deploying a new server version and automatically blocking a updated set of outdated clients sounds wrong to me since admins might not check or know upfront.

@skjnldsv
Copy link
Member Author

Clients, mobile and desktop, support a 5 year range, so clients drop Server support after server version is 5 years old. This is done to ensure we can always maintain a single client version going forward.

That should still mean that we should block versions under 5 years.
Which means 2019, and not the current 2017.

But I agree, adding a setup warning seems good as well.

@AndyScherzinger
Copy link
Member

That should still mean that we should block versions under 5 years.
Which means 2019, and not the current 2017.

Yes, absolutely 👍

But I agree, adding a setup warning seems good as well.

Also on the same page here 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants