43
« on: July 21, 2008, 11:13 AM »
@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).