4 ms·

How about we don't build an auto-updater? Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete soft

How about we don't build an auto-updater? Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. Touching files on a user's system should be treated as a rare special occurrence. If a server is involved with the app, build a stable interface and think long and hard about every change. Meticulously version and maintain everything. If a server is involved, it is completely unacceptable for a server-side change to break an existing user's local application unless it is impossible to avoid - it should be seen as an absolute last resort with an apology to affected customers (agree with OP on this one). It is your duty to make sure _all_ of your users are able to continue using the same software they installed in exactly the same way for the reasonable lifetime of their contract, the package, or underlying system (and that lifetime is measured in years/decades, with the goal of forever where possible. Not months). You can, if you must, include an update notification, but this absolutely cannot disrupt the user's experience; no popups, do not require action, include an "ignore forever" button. If you have a good product with genuinely good feature improvements, users will voluntarily upgrade to a new package. If they don't, that is why you have a sales team. Additionally, more broadly, it is not your app's job to handle updates. That is the job of your operating system and its package manager. But I understand that Windows is behind in this regard, so it is acceptable to compromise there. We go a step further at my company. Any customer is able to request any previous version of their package at any time, and we provide them an Internet download page or overnight ship them a CD free of charge (and now USB too).

Hackbraten 2y ago
> Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. That sounds like a good idea. Unless you’re the vendor, and instead of 1000 support requests for version N, you’re now facing 100 support requests for version N, 100 for N−1, 100 for N−2, …, and 100 for N−9.
- cdmyrm 2y ago
  You're allowed to have a support matrix. You can refuse to support versions that are too old, but you can also just... let people keep using programs on their own computers.
  - ddingus 2y ago
    Yep. And anyone who does will find a percentage of users figure it out and then just get back to work.
- ddingus 2y ago
  Have been there, done that. The answer is a support window. If they are in bounds and have active maintenance contracts, support them. If not, give them an option to get on support, or wish them luck. Then the other answer is to really think releases through. None of it is cheap. But it can be managed.
- worewood 2y ago
  Besides what others said, realistically, the effort to support N versions is not O(n). I think it's something like O(log n), because code will largely be shared between versions - you're not doing a rewrite every release.
pjerem 2y ago
I do agree with you but I think that unfortunately you are wrong on the job of updates. You have an idealistic vision that I share but well, it remains idealistic. Apart from, maybe, Linux distros, neither Apple or Microsoft are providing anything to handle updates that isn’t a proprietary store with shitty rules. For sure the rules are broken on desktop OSs but by the meantime, you still have to distribute and update your software. Should the update be automatic ? No. Should you provide an easy way to update ? I’d said that at the end it depends on if you think it’s important to provide updates to your users. But should you except your users or their OSs to somehow update your app by themselves ? Nope.
- cdmyrm 2y ago
  This is actually precisely how package management works in Linux today... you release new versions, package maintainers package and release them, while ensuring they actually work. This is a solve problem, it's just that nobody writing JavaScript is old enough to realize it's an option.
  - pjerem 2y ago
    And that's why I said "apart for Linux". Where are the package maintainers on the OSes everyone uses ? (and don't think that's sarcasm, I'm writing this comment on my linux desktop).
    - xrisk 2y ago
      Homebrew and chocolatey?
      - dingdingdang 2y ago
        My exact thought as well, simply point the user to a well established and proper channel for auto updates and then the dev simply needs to upload/release to said repos when a new version is put out. As an aside: Chocolatey is currently the only (stable/solid) way to consistently keep things up to date on the Win platform in my book.
PeterStuer 2y ago
Sounds like you come from the B2B, consultancyware or 6÷ figure/year license world. For the vast realm of <300$/year products, the ones that actually use updaters, all your suggestions are completely unviable.
- sigmoid10 2y ago
  And it's not like B2B doesn't get whacked by bad software or bad actors regulalry. The idea that software updates itself is vastly more benefitial than harmful in the very long term. There so many old machines running outdated software in gated corporate networks, they will get owned immediately once a single one of them is compromised in any way. They are literally trading minor inconveniences for a massive time-bomb with a random timer.
  - buran77 2y ago
    The two sides of your thought are going head to head. "Gated corporate networks" don't benefit from software that "updates itself" (unless we're talking about pure SaaS). It's exactly where auto-updating is completely useless because any company with a functioning IT will go out of its way to not delegate the decisions of when to update or what features are forced in out to the developer and their product manager. Auto-updates mostly ever practically happen for software used at home or SMB which might not have a functioning IT. If security is the concern why not use auto-updates only for security updates? Why am I gaining features I explicitly did not want, or losing the ones which were the reason I bought the software in the first place? Why does the dev think I am not capable of deciding for myself if or when to update? I have a solid theory of why and it involves an MBA-type person thinking anyone using <$300 software just can't think for themselves and if this line of thought cuts some costs or generates some revenue all the better.
    - sigmoid10 2y ago
      You're not thinking of it long term. In the short term you might be better off deciding when to update yourself, but in the long term you will be infinitely worse off because the reality of business practice is to delay updates until something catastrophic happens just to save a few bucks in the IT department. This approach merely means your system will run smoother over short time scales, while it becomes a complete clusterfuck over long time scales.
pjmlp 2y ago
Windows Store and winget. Developers are the ones behind the times.
klabb3 2y ago
> How about we don't build an auto-updater? Sure. I’d rather have it be provided by the platform. It’s a lot of work to maintain for 5 OSs (3 desktop, 2 mobile). > we should try our best to release complete software to users that will work as close to forever as possible This isn’t feasible. Last I tried to support old systems on my app, the vendor (Apple) had stopped supporting and didn’t even provide free VMs. Windows 10 is scheduled for non-support this year (afaik). On Linux glibc or gtk will mess with any GUI app after a few years. If Microsoft, Google and Apple can’t, why the hell should I as a solo app developer? Plus, I have 5 platforms to worry about, they only have their own. > Touching files on a user's system should be treated as a rare special occurrence. Huh? That’s why I built an app and not a website in the first place. My app is networked both p2p and to api and does file transfers. And I’m supposed to not touch files? > If a server is involved with the app, build a stable interface and think long and hard about every change. Believe me, I do. These changes are as scary as database migrations. But like those, you can't avoid them forever. And for those cases, you need at the very least to let the user know what’s happening. That’s half of the update infrastructure. Big picture, I can agree with the sentiment that ship fast culture has gone too far with apps and also we rely on cloud way too much. That’s what the local first movement is about. At the same time, I disagree with the generalization seemingly based on a narrow stereotype of an app. For most non-tech users, non-disruptive background updates are ideal. This is what iOS does overnight when charging and on WiFi. I have nothing against disabling auto updates for those who like to update their own software, but as a default it would lead to massive amounts of stale non-working software.
- RadiozRadioz 2y ago
  > file transfers. And I’m supposed to not touch files? I'm pretty sure you know what I meant, it's obvious from context. System program files. The files that are managed by your user's package manager (and by extension their IT department)
  - klabb3 2y ago
    There isn’t a package manager in many cases: windows store requires a MS account. macOS app store nerfs apps by sandbox restrictions. Linux has so many flavors of package managers it’s death by 1000 paper cuts. None of the major bundlers like flutter, electron and tauri support all these package managers and/or app stores. Let alone running the infrastructure for it. Which leaves you with self-updaters. I definitely agree ideally it shouldn’t be the applications job to update itself. But we don’t live in that world atm. At the very least you need to check for updates and EOL circuit breakers for apps that aren’t forever- local only apps. Which is not a niche use-case even if local-first infra was mature and widely adopted, which it very much isn’t. Anyway, my app works without internet, pulls no business logic at runtime (live updates) and it uses e2ee for privacy. That’s way more than the average ad-funded bait-and-switch ware that plague the majority of commercial software today. I wish I didn’t have to worry about updates, but the path to less worries and healthy ecosystem is not to build bug-free forever-software on top of a constantly moving substrate provided largely by corporations with multiple orders of magnitude more funding than the average software development company.
itsthecourier 2y ago
I have clients who have been running for more than 10 years in old versions for diverse reasons. I design a layer of backward compatibility in our apis to keep updating optional. it works well
rs186 2y ago
> How about we don't build an auto-updater? Auto-updaters are the most practical and efficient way of pushing updates in today's world. As pointed out by others, the alternative would be to go through app store's update mechanism, if the app is distributed via app store in the first place, and many people avoid Microsoft store/MacOS app store whenever possible. And no developer likes that process.
theragra 2y ago
For me, Windows is thousand years ahead in this regard. I download software, and run it. And it works 99.9% of the time. Yes, I have a chance of getting a virus. Happened one time in 30 years I'm using Windows. (More in DOS times). Linux, I got burned again yesterday. Proxmox distribution has no package I need in their repository. I am trying to use Ubuntu package - does not work. I try to use debian - too old version. How do I solve this? By learning some details of how the Linux distributions and repositories work, struggling some more and finding customly built version of .deb. Okay, I can do it, kinda, but what about non-IT person? Software without dependencies is awesome. So, docker is something I respect a lot, because it allows the same model (kinda).

Hackbraten 2y ago

> Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. That sounds like a good idea. Unless you’re the vendor, and instead of 1000 support requests for version N, you’re now facing 100 support requests for version N, 100 for N−1, 100 for N−2, …, and 100 for N−9.

cdmyrm 2y ago
You're allowed to have a support matrix. You can refuse to support versions that are too old, but you can also just... let people keep using programs on their own computers.
- ddingus 2y ago
  Yep. And anyone who does will find a percentage of users figure it out and then just get back to work.
ddingus 2y ago
Have been there, done that. The answer is a support window. If they are in bounds and have active maintenance contracts, support them. If not, give them an option to get on support, or wish them luck. Then the other answer is to really think releases through. None of it is cheap. But it can be managed.
worewood 2y ago
Besides what others said, realistically, the effort to support N versions is not O(n). I think it's something like O(log n), because code will largely be shared between versions - you're not doing a rewrite every release.

pjerem 2y ago

I do agree with you but I think that unfortunately you are wrong on the job of updates. You have an idealistic vision that I share but well, it remains idealistic. Apart from, maybe, Linux distros, neither Apple or Microsoft are providing anything to handle updates that isn’t a proprietary store with shitty rules. For sure the rules are broken on desktop OSs but by the meantime, you still have to distribute and update your software. Should the update be automatic ? No. Should you provide an easy way to update ? I’d said that at the end it depends on if you think it’s important to provide updates to your users. But should you except your users or their OSs to somehow update your app by themselves ? Nope.

cdmyrm 2y ago
This is actually precisely how package management works in Linux today... you release new versions, package maintainers package and release them, while ensuring they actually work. This is a solve problem, it's just that nobody writing JavaScript is old enough to realize it's an option.
- pjerem 2y ago
  And that's why I said "apart for Linux". Where are the package maintainers on the OSes everyone uses ? (and don't think that's sarcasm, I'm writing this comment on my linux desktop).
  - xrisk 2y ago
    Homebrew and chocolatey?
    - dingdingdang 2y ago
      My exact thought as well, simply point the user to a well established and proper channel for auto updates and then the dev simply needs to upload/release to said repos when a new version is put out. As an aside: Chocolatey is currently the only (stable/solid) way to consistently keep things up to date on the Win platform in my book.

PeterStuer 2y ago

Sounds like you come from the B2B, consultancyware or 6÷ figure/year license world. For the vast realm of <300$/year products, the ones that actually use updaters, all your suggestions are completely unviable.

sigmoid10 2y ago
And it's not like B2B doesn't get whacked by bad software or bad actors regulalry. The idea that software updates itself is vastly more benefitial than harmful in the very long term. There so many old machines running outdated software in gated corporate networks, they will get owned immediately once a single one of them is compromised in any way. They are literally trading minor inconveniences for a massive time-bomb with a random timer.
- buran77 2y ago
  The two sides of your thought are going head to head. "Gated corporate networks" don't benefit from software that "updates itself" (unless we're talking about pure SaaS). It's exactly where auto-updating is completely useless because any company with a functioning IT will go out of its way to not delegate the decisions of when to update or what features are forced in out to the developer and their product manager. Auto-updates mostly ever practically happen for software used at home or SMB which might not have a functioning IT. If security is the concern why not use auto-updates only for security updates? Why am I gaining features I explicitly did not want, or losing the ones which were the reason I bought the software in the first place? Why does the dev think I am not capable of deciding for myself if or when to update? I have a solid theory of why and it involves an MBA-type person thinking anyone using <$300 software just can't think for themselves and if this line of thought cuts some costs or generates some revenue all the better.
  - sigmoid10 2y ago
    You're not thinking of it long term. In the short term you might be better off deciding when to update yourself, but in the long term you will be infinitely worse off because the reality of business practice is to delay updates until something catastrophic happens just to save a few bucks in the IT department. This approach merely means your system will run smoother over short time scales, while it becomes a complete clusterfuck over long time scales.

pjmlp 2y ago

Windows Store and winget. Developers are the ones behind the times.

klabb3 2y ago

> How about we don't build an auto-updater? Sure. I’d rather have it be provided by the platform. It’s a lot of work to maintain for 5 OSs (3 desktop, 2 mobile). > we should try our best to release complete software to users that will work as close to forever as possible This isn’t feasible. Last I tried to support old systems on my app, the vendor (Apple) had stopped supporting and didn’t even provide free VMs. Windows 10 is scheduled for non-support this year (afaik). On Linux glibc or gtk will mess with any GUI app after a few years. If Microsoft, Google and Apple can’t, why the hell should I as a solo app developer? Plus, I have 5 platforms to worry about, they only have their own. > Touching files on a user's system should be treated as a rare special occurrence. Huh? That’s why I built an app and not a website in the first place. My app is networked both p2p and to api and does file transfers. And I’m supposed to not touch files? > If a server is involved with the app, build a stable interface and think long and hard about every change. Believe me, I do. These changes are as scary as database migrations. But like those, you can't avoid them forever. And for those cases, you need at the very least to let the user know what’s happening. That’s half of the update infrastructure. Big picture, I can agree with the sentiment that ship fast culture has gone too far with apps and also we rely on cloud way too much. That’s what the local first movement is about. At the same time, I disagree with the generalization seemingly based on a narrow stereotype of an app. For most non-tech users, non-disruptive background updates are ideal. This is what iOS does overnight when charging and on WiFi. I have nothing against disabling auto updates for those who like to update their own software, but as a default it would lead to massive amounts of stale non-working software.

RadiozRadioz 2y ago
> file transfers. And I’m supposed to not touch files? I'm pretty sure you know what I meant, it's obvious from context. System program files. The files that are managed by your user's package manager (and by extension their IT department)
- klabb3 2y ago
  There isn’t a package manager in many cases: windows store requires a MS account. macOS app store nerfs apps by sandbox restrictions. Linux has so many flavors of package managers it’s death by 1000 paper cuts. None of the major bundlers like flutter, electron and tauri support all these package managers and/or app stores. Let alone running the infrastructure for it. Which leaves you with self-updaters. I definitely agree ideally it shouldn’t be the applications job to update itself. But we don’t live in that world atm. At the very least you need to check for updates and EOL circuit breakers for apps that aren’t forever- local only apps. Which is not a niche use-case even if local-first infra was mature and widely adopted, which it very much isn’t. Anyway, my app works without internet, pulls no business logic at runtime (live updates) and it uses e2ee for privacy. That’s way more than the average ad-funded bait-and-switch ware that plague the majority of commercial software today. I wish I didn’t have to worry about updates, but the path to less worries and healthy ecosystem is not to build bug-free forever-software on top of a constantly moving substrate provided largely by corporations with multiple orders of magnitude more funding than the average software development company.

itsthecourier 2y ago

I have clients who have been running for more than 10 years in old versions for diverse reasons. I design a layer of backward compatibility in our apis to keep updating optional. it works well

rs186 2y ago

> How about we don't build an auto-updater? Auto-updaters are the most practical and efficient way of pushing updates in today's world. As pointed out by others, the alternative would be to go through app store's update mechanism, if the app is distributed via app store in the first place, and many people avoid Microsoft store/MacOS app store whenever possible. And no developer likes that process.

theragra 2y ago

For me, Windows is thousand years ahead in this regard. I download software, and run it. And it works 99.9% of the time. Yes, I have a chance of getting a virus. Happened one time in 30 years I'm using Windows. (More in DOS times). Linux, I got burned again yesterday. Proxmox distribution has no package I need in their repository. I am trying to use Ubuntu package - does not work. I try to use debian - too old version. How do I solve this? By learning some details of how the Linux distributions and repositories work, struggling some more and finding customly built version of .deb. Okay, I can do it, kinda, but what about non-IT person? Software without dependencies is awesome. So, docker is something I respect a lot, because it allows the same model (kinda).