-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
41 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
# Delta Updates | ||
<AppliesTo all /> | ||
Delta updates provide speedy updates for even the biggest of applications. | ||
|
||
By default, as long as there is a previous release in your `--outputDir` / `-o` directory, Velopack will automatically generate a delta when creating a new release. | ||
|
||
:::tip | ||
If you don't have the latest local release, eg. you're running in CI, you can use the `vpk download` command to automatically fetch it so delta's can be created. | ||
::: | ||
|
||
Delta packages use [Zstandard](https://github.com/facebook/zstd) to create binary patches of individual files in your package. Due to limitations of Zstandard, no single file can be bigger than 2 GB. | ||
|
||
## Optimising for size | ||
The default parameters picked for patch generation are to provide a good balance of size and speed. | ||
If you would like to optimize for size, you can do this with the `--delta BestSize` argument. | ||
YMMV, for some appliations this may give you big size savings, for others it may not. Either way it will be a lot slower, about on-par with the `bsdiff` algorithm. | ||
|
||
## How delta's work | ||
During updates, Velopack will look for possibly more than one delta to download. Imagine you have published the following releases: | ||
- `1.0.0` | ||
- `1.0.1` | ||
- `1.0.2` | ||
- `1.0.3` | ||
|
||
If a user has not opened your app in a while, and has `1.0.0` installed, the next time they open the app, | ||
3 delta's will be downloaded: `1.0.1-delta`, `1.0.2-delta`, and `1.0.3-delta`. | ||
|
||
The previously downloaded/installed package is stored in `%LocalAppData\{packId}\packages`, so Velopack will then apply those 3 delta's sequentially | ||
on top of the local package that exists in that directory. | ||
|
||
Once the delta's have been applied, and the `1.0.3` release has been reconstructed, it will be ready for applying. | ||
|
||
There is a heuristic in Velopack which will attempt to decide whether it is better to download N delta's or download the latest full release instead. | ||
This is based on a number of factors (eg. size of the full release, sum size of the delta's, total number of delta's between the current & target version). | ||
|
||
## GitHub Releases | ||
There is special support for GitHub Releases in `UpdateManager` which will search through a number of previous GitHub Releases for available delta's. | ||
This means any one GitHub release must only have 1 full package and 1 delta update to facilitate proper updating. | ||
|
||
## Disabling delta's | ||
If for some reason you don't want to deploy delta's, you can disable them with the `--delta none` argument. |