DASD
@pezetko
If several incremental updates don't get you the same result as one clean install, the updater is complete trash and its programmer(s) should consider changing professions.

Bugs? Like Windows, Firefox, Adobe, Autodesk products? etc…

DASD
Dependencies would break….

In production even os updates are fully controlled to avoid broken system in the middle of the production.

DASD
The main version would be the version you keep updating. If something actually breaks you can install a previous build from the daily builds and work on that.

And you lost at least a lot of of production time (download and install of the old build isn't instant).

DASD
Every modern game with online features has an automatic update function.

Do a professional players update the game during tournaments? I don't think so.

If you don't have those 3 minutes, script that. There are plenty of automation tools that could help you do an automatic update system based on daily build's rss feed and your specific paths.

Go for that, it will pays you off if you think so.

But this doesn't suits everybody as you can see.

Actually the way how Houdini separates each build's installation in perfectly clean and transparent way is the most valuable thing that allowed us to roll out couple of different builds at once without any worry they will affect each other and couse some troubles or delays in production.

Bugs? Like Windows, Firefox, Adobe, Autodesk products? etc…

In production even os updates are fully controlled to avoid broken system in the middle of the production.

- An update can contain bugs, yes. But the update process is usually not responsible for creating the (bugs). Bugs are introduced with the addition of features in code, or through (ironically) other bug-fixes.
I already described how the risk can be minimized for a big production company: One person updates. That person tests relevant functions. If she/he does not discover issues, the rest of the company updates.
This is exactly the same thing that should happen with daily build updates and for pretty much the same reasons.
So nothing changes there, but the update per user is faster with an updater. In case an issue is discovered after the company wide update, the update method is inferior, because you would have to install a previous version. But this risk is minimized and the fix is apparent. So on average this would be a rare occurance and a quick fix. As a result the updater process is faster on average.

Do a professional players update the game during tournaments? I don't think so.

Actually, with League of Legends that could theoretically happen between matches. Ranked games - witch could qualify you for professional play - also always require the latest build. Occassionally bugs are introduced or discovered after an update. In that case a hot-fix and a warning is distributed.
In production, the question is one of time-frame and necessety. If your product has to be finished in a week or so, hardly anybody would update unless it fixes a huge bug that affects the production. If your production takes months or even more than a year, there will likely be occasions where it makes sense to update everyone's build to fix various issues that were discovered over time or to make work a bit easier with new features.

If you don't have those 3 minutes, script that. There are plenty of automation tools that could help you do an automatic update system based on daily build's rss feed and your specific paths.

I did not know that. But as far as I understand those solutions can only automate the download and install process. They do not work incrementally as an updater would, right? And that misses the advantages of the process I suggest.

Log on and click download - 25 seconds.
Double click installer and install - ~2 min.
Update shortcut to Houdini - 15 sec
Total time ~3 min.

I actually went through the process just now. - For science!
Download took about 13 minutes.
Install process took about 5 minutes (on an SSD).

That's actually far less than I thought. And honestly it kinda diffuses the speed gain argument. Still, an updater would probably need about a minute to download and install (a few megabytes).
The interesting part is that the updater would become a better solution the bigger Houdini gets.

- Well, at this point I am playing “devil's advocate” to explore this idea, but I think I am still doing quite well.

I hardly see any advantage of incremental updates beside saving time. And time as any value is relative to other factors.

In my work such value is sandboxing. That's why I refer to work on Linux. In Linux based environments, sandboxing is A) crucial B) easy to achieve. It is straight, coherent, logical and reliable way of controlling chaos. If I open a scene created 2 years ago in my environment, it should look exactly the same. Until now this works for any professional application I am aware of. Otherwise it wouldn't be properly deployed and I would avoid it. Maya, Nuke, Houdini, whole bunch of renderers and utility programs + compilers, libraries, interpreters, all are read-only after installation, set up with reproducible steps, which are also scriptable. Thanks to that I'm be able to deploy them on any computer / site without third-party intervention. Its a matter of security and reliability for any clusters / web server / file server / CG pipeline I am aware of.

Incremental update would break the very principle of pipeline reliability. If it works for Adobe, this is only because the majority of their user base are freelances, who don't know they do a wrong thing, nor they are able to do it right. They would have to invest a lot of money and time in Windows' applications deployment architecture (Windows Server / domain etc). I hear it constantly how they are scared to update their applications, how they wait for first security patches, how they are bind to old/buggy version of an application for the entire show or have alternative hard drives with many variants of the system and/or apps. Madness. For the rest of the bunch (studios), Adobe-like deployment is plain stupid and creates a lot of problems with virtually zero advantages.

Saying that… creating separate install path for Indie users to help them deal with technical constrains, is yet another story and different sort of decision. Not very technical so to speak.

DASD
I've said this in another thread, but was shut down for my apparent blasphemy:
Houdini needs an optional update function.
With optional I mean that the daily builds should still be available, but instead of pulling and installing the whole installer you should be able to just pull the updates within Houdini.
The bandwidth that could be saved is only growing. The time that could be saved on installs is only growing. The technological foundation existed for ages. So the only reason not to do it, is the effort that goes into developing the update system. Should be worth it in the long run, though.

+1

Can't we have both options?