ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Find And Run Robot

Updates: Patches?

(1/2) > >>

herojoker:
To reduce server load creating patches (instead of having to download the whole package again) might be quite useful!
I assume you use a versioning system, so creating patches (even on the fly, at the first request) should be easy.

jgpaiva:
I think that'd create extra problems: if someone doesn't download every single version, that person would have to download a few patches, complicating the instalation process.
Also, only a few people download every version, it doesn't compare to the number of people who download the software for the first time ;) (at least, that's what I think! :D)
It would make it easier for us, the ones who download it on every version, but I don't really care for a few MBs a day, and I think it wouldn't compensate the hassle it'd be for mouser to create several packages, etc.

mouser:
It's not technically that hard to do.. but it would involve a lot of extra work on my part building these different ways of getting the program and uploading the different files.  If i didn't have so many different programs i maintain and didn't update as frequently as i do it might be something i'd consider, but as it is now it's just not something i plan on.

herojoker:
@jgpaiva: That's why I mentioned automatic patch generation... Person A has an old version for which no patch exists yet, so it's just created on the fly with help of the repository. It should just be a binary patch! You don't even need automatic building[compiling] here!
I now see that there isn't even a (classical) repository needed (like SVN or CVS) but only all previous FARR versions. One could also limit the number of previous versions to, let's say, 20 or so. All older versions cannot be patched and a complete download is needed.
Additionaly all old patches might be deleted, so there are only 20 patches online.

To sum up the scenario:
First possibility: The server contains all FARR versions, if a patch request comes in, the desired patch is (if not already there) created (automatically; a binary diff?), the url to the patch is returned.
Second possibility: The server contains only a certain amount of FARR versions and all patches from older version to the newest (or to some major/security/... builds) are stored (created offline, then uploaded by mouser?), if a patch request comes in, the url to the patch is returned.

Of course mouser could freely change the parameters I used in the second possibility (and there may be many more ways to do it).
I think the latter way is not so difficult to do but the first one is quite flexible  ;)

@mouser: Oh, ... yes. It would definitely need some changes :) But it could also simplify your whole work process.
I have automatic patch generation (in the 2nd case) and uploading, and an automatic post in the update thread (based on the changelog) in my mind... Writing a program which does this could be used for all your apps!

The first case would reduce the work you have to do because patches are created on the server side (don't know your infrastructure).

lanux128:
the differential patch idea is good since we have the DCUpdater to check and download the new & changed files only. :)

Navigation

[0] Message Index

[#] Next page

Go to full version