3 ms·

> You mentioned storing diffs against every previous version I didn't say you need to. Eg, with my software project, I wrote an update system that supported d

> You mentioned storing diffs against every previous version I didn't say you need to. Eg, with my software project, I wrote an update system that supported diff upgrading against the two latest versions, and anyone still running an older version had to download a full update. > You could upgrade from any previous version by applying all the diffs in sequence At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code.

true_religion 15y ago
> At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update Well you wouldn't really need to but it would be a good sanity check on the client side. The common case could be that people are simply keeping up with the stable edge w/o patching binaries themselves out of band---that's the case with some desktop linux variants.
leif 15y ago
> At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code. The obvious way to handle this is to store full package "snapshots" on "major" version releases (probably upstream releases for packages with lots of local patching, or "one level up from the bottom" releases) and diffs in between. That is not a lot of code if you already have a sane way of managing release numbers within your package manager, which you hopefully do.

3 ms·

> You mentioned storing diffs against every previous version I didn't say you need to. Eg, with my software project, I wrote an update system that supported d

by nuclear_eclipse 15y ago

true_religion 15y ago
> At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update Well you wouldn't really need to but it would be a good sanity check on the client side. The common case could be that people are simply keeping up with the stable edge w/o patching binaries themselves out of band---that's the case with some desktop linux variants.
leif 15y ago
> At that point you also need to make sure that you aren't downloading more in the process of applying a series of patches than you would need to download for a full update, which also means you need to start being aware of multiple update options, which balloons the complexity of your update code. The obvious way to handle this is to store full package "snapshots" on "major" version releases (probably upstream releases for packages with lots of local patching, or "one level up from the bottom" releases) and diffs in between. That is not a lot of code if you already have a sane way of managing release numbers within your package manager, which you hopefully do.