Rethink update preferences
When we originally designed Software, we were focused on doing the right thing by default - that is, automatically taking care of updates, so people don't have to do the work. We'd automatically check for updates, automatically download them, and automatically install them where possible.
There was some push back against this, with people citing various concerns about the automatic behaviour. That led to what we have today: a single "automatic updates" switch.
The most obvious problem with this preference is that the off state is unclear. Automatic updates combines several behaviours, so what does it mean to turn it off?
I think that we can also question whether the single automatic updates switch meets expectations. After a little investigation, it seems that there's a range of motivations for people to change Software's updating behaviour, including:
- “I have a low power machine and am a developer. I don't want any background operations automatically happening, which can interfere with other tasks (watching videos, compiling, etc).”
- “I'm a developer and want fine-grained control over when updates are checked and installed, so I can control which versions of apps, libraries and runtimes I have installed. Preferably I'd do this from the CLI, with no interference.”
- “I have very limited network bandwidth, and automatic update checking makes my network unusable for other tasks.”
- “I power off my machine at the end of each day, and would prefer to be running the latest available versions. I would therefore like to be able to have all available updates installed when I power off.”
- “I don't want Software to run in the background, so I can save memory.”
Addressing each of these cases might result in preferences that look like this:
This turns the automatic updates setting from a binary into a tri-state. It also adds a preference for the automatic download period. It seems much clearer to me, but I think that we seriously have to consider the complexity cost, particularly given the existing complexities around updates, and the associated reliability issues.
It would be great to get some developer input here. Is there a way we could simultaneously simplify the updates behaviour and increase the clarity of the options?