No reason for sarcasm...
I don't see any trace of "sarcasm" in any of my replies. You are assuming this because you still don't believe what I'm trying to say, which it's entirely serious facts, not a joke.
Also this is your product. Only you can make sure all necessary files are "precisely the ones they are supposed to be".
Not really, the files on our server ARE obviously "precisely the ones they are supposed to be", but when they are distributed online they CAN possibly suffer from delays in replication over the 270+ local Cloudflare nodes.
And it's PRECISELY because of this, our program CHECKED them and tries to re-download them if they failed the check. So, it's doing precisely the job is supposed to do: trying in every way to get you the correct files, instead blindly trusting whatever it comes from the internet.
As a user I do installations and updates, how am I supposed to know what files have to go where? It's your responsibility as a developer to program your update and installation processes to end up with the files I need in order for them to work, isn't it?
And that's precisely why in the Sticky thread is indicated which files you shouldn't worry about.
After all it's a problem of your update servers that started all the problems to begin with.
That is wrong, the only problems are caused by the only servers we don't have any control on. And as explained countless of times, if we didn't use the Cloudflare distribution system, nobody would be able to download anything, because "our" server would never able to handle such kind of load, something we saw *multiple* times on other popular releases, where nobody was able to download anything, something that never happened here.
And precisely because the server we can't control *might* be outdated, that our updater works that way, otherwise (again) you wouldn't even suspect of a problem.
And I'm not sure if you understand my concept of a version number... I don't want to see a "mythical number" somewhere, but I rely on propper programming, where a software version is done with every file precisely where it's supposed to be in the state it needs to be in. When that's done this version gets a number. So when a user has an issue, you as a developer have information on what is where, just by a user telling you wich version of your software he is talking about. That should actually make troubleshooting even easier.
Why are you repeating something that has been discussed so many times, over and over ? There are two ways to show a "version number" and is:
1) By faking it, assuming that if you run an update, you "must" have the latest version, because on connection, a file or two might be used as samples, and saving it somewhere, with the installer reading that information and telling you have the latest version.
2) By doing it properly, and the real way to do it properly is with a really "fault tolerant" install that would take a large impact on your system, your connection and our bandwidth because, it should work this way:
- Before doing any update, there should be a first pass checking all files, making a list of the outdated ones and doing a complete backup of all files that WILL be downloaded. This will take extra time and some disk space that, in the event all files are updated ( maybe not likely, but possible ), double the disk space of the program normally takes.
- All files scheduled to be updated should be downloaded and, after they are all downloaded, they should be checked again. If even a SINGLE file failed the check, ALL files from the backup should be restored, since we cannot risk having a mix-up of old and new files so, you'll be back to the previous version. Only if ALL files passed the check, we could reliably show a "version number", because we checked the new version is really complete and coherent.
Option #2 is what is called a "fault tolerant" update, which nobody really use, because not only is way slower and put lots of strain on servers, but it can ALSO be very frustrating to users, because you'll be rolled back to version you started with, possibly because a single file wasn't updated on your local node.
That's why most updaters prefer Option #1, which is way lighter on servers, it shows a version number, it makes users feel safe, but it's not really reliable.
We are using a 3rd approach, which is something in between: we DO check all files, and we just try to re-download only the failed one on the next start, instead of trashing everything and redo everything from start if a single outdated file.
And this, of course, is the best approach because, it's not as if files get outdated "forever", eventually all nodes will get all files so, any issue will self-correct automatically.
