I would not force an update on a user.

First, it tends to happen that someone’s “work flow” or “process” becomes dependent on certain behavior of your app. If you change that, it will cause chaos and anarchy and whining to someone’s boss that those mean IT people are stopping me from doing work and they need to fix it NOW.

Secondly, like you said, sometimes people don’t need to or have time to upgrade right now. Imagine a critical report is due very soon and you can’t get your work done because the app is updating and you’re stuck waiting for it.

I think the best solution is to have a written policy somewhere that states that you support versions 2.0.0.3 to 2.0.0.5. and that if you are outside that window you either have to upgrade to get support or you are on your own.

As with any question, the answer is “it depends”.

If your application works as before after the update and the update is critical to the security of the user and the average user is not tech-savy enough to decide himself, then I think forced auto-updating is a good thing.

If your application connects different users in a competing scenario, it’s absolutely critical that all are using the same software. Forced updates are the default behaviour here. Think of online games for example.

Nudging Users to update by themselves by softer means like only supporting the three most recent versions is quite normal.

Forcing the users to update in other scenarios is considered a Bad Thing ™. The user bought the software he installed. If you change it without his consent, it will not make him a happy customer.

Forcing users to whatever is a Bad Thing (TM). Forcing to download and install stuff is even more rude. And your reasoning is not sound either.

If you don’t want to support some versions, do that. You need not sabotage my ability to run the program to achieve that goal. Just start any support session with version request and stop if it’s out of range.

I may be more interested in just running what I used to than “support”. If there is a problem that is indicated as fixed, I can go out and upgrade. At my pace, voluntarily.

It’s really not a problem for you as a software developer, but for your product manager who needs to think about the consequences.

“Forcing” is bad if it forces the user to upgrade right now. If the user is in a rush to finish their work, and you hold them up by forcing an upgrade, that’s very bad style, especially if the upgrade takes a long time. Pestering the user to update is a bit better.

Is there a cost involved for you if the user does not upgrade? For example if the existing app takes lots of resources on your server, and the new app doesn’t, or the existing app is buggy and people call support all the time, and the new app reduces this. That’s a good reason for not enforcing, but strongly encouraging an update.

If you found bugs in the old version that are so severe that the risk of running the old verion outweighs the inconvenience of upgrading, that’s another reason possibly to enforce an upgrade.

And before you force an upgrade, you better be one million percent sure that the new version doesn’t have any fatal bugs.

In some industries, configuration control is not just important, it is essential – and that extends to the development environment, as well as the project source code… it is not unknown to have multiple hard-drives with different configurations.

These sort of projects require ANY change to the environment to be assessed, verified and validated. This includes such mundane things as Windows Update and/or any other such ancillary packages. Similarly on Linux systems, undate and apt most definitely do not run overnight…

An automatic or forced update would be a Bad Thing.

Now, I appreciate not every project, or workplace has those constraints – but you need to be aware of any such issues your customer may have!