[ctxc]

Counter point for general software: some people don't upgrade software for _years_, due to which vendors have two problems - 1. Open security vulnerabilities 2. Necessity to maintain backward compatible infra

To offset this, two channels of releases can be maintained - one for security fixes, another for general features etc. But again here, we run into problems where maintenance of two channels isn't economical, and you end up testing security fixes on various versions.

How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?

[chockchocschoir]

> How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?

There is an easy way to solve this problem. Default to auto updates, allow people to turn it off, by acknowledging what that means. Most users use whatever is the default anyways. Vendors gets to push their updates, users who don't want those, can reject them. If someone gets hacked because they turned off auto update, the vendor won't be on the hook for it, because the user said they were aware of it when they turned it off.

I think the core problem here is not that people are asking for auto updates to be off by default, they simply want to have the option. And frankly, for professional use cases, you have to be able to turn off auto updates, as otherwise it'll harm the workflow as you can't control when the update happens.

[ctxc]

Yup, makes perfect sense. Thanks!

[cmeacham98]

I'll give you the same answer I gave people when Microsoft started doing the same nonsense with Win10:

I totally agree your average end user is poor at managing updates themselves and thus it is justified to enable auto-updates by default. What that does not justify is totally removing the ability to turn them off. Feel free to make it a little harder to disable: the user has to run a CLI command or something, but the option should be there.

> How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?

If you go through the extra effort to disable updates and don't grab a security fix, that's on you. How is "you have to do exactly what I tell you - wait why is nobody using my software?????" a best compromise for users? What are users expected to do when an upgrade breaks something and they can't downgrade?

[ctxc]

Sensible defaults, but built for the power user. Makes sense.

[anonymousab]

The old argument is that anything a power user can do, a malicious script can do too. So such options must be removed entirely if there is any chance of a less technically inclined user being tricked into doing it.

[DangitBobby]

This argument doesn't hold water. At the point malicious software is already on the machine, an automated update doesn't help. And if someone is inducing you to manually turn off automatic updates for malicious reasons... they could just as easily be inducing you to install malicious software directly.

[MiddleEndian]

Make updates that are appealing enough that users want them.

[cerved]

1. Open security vulnerabilities

sounds like a user problem

[ctxc]

A user problem that can have a very real impact on your product.

"x ProductX users impacted by Ransomware" will make headlines, your "well yes, we fixed it in v2.7.8 months back" won't.