Non-optimal update behavior with Squirrel.Windows

[fasterthanlime]

Squirrel.Windows works well with simply all releases served statically: Squirrel/Squirrel.Windows#517

However nuts is really convenient for many different reasons, but currently, it serves a truncated 'RELEASES' file, with -delta files filtered out.

The result is (from what I'm seeing)

• squirrel downloads the RELEASES file
• squirrel downloads the full .nuget package once
• squirrel notifies that there's a new version
• squirrel downloads the RELEASES file again
• squirrel downloads the full .nuget package a second time
• squirrel unpacks the upgrade

Ideally, what would happen is this:

• squirrel downloads the RELEASES file
• squirrel notifies that there's a new version
• squirrel downloads the delta .nuget package once
• squirrel applies the delta upgrade

Since it looks like -delta nupkg are filtered on purpose, I was wondering what was the thinking behind it?

[fasterthanlime]

For reference, here's the commit introducing delta filtering: fded8af#diff-6d186b954a58d5bb740f73d84fe39073R233

[SamyPesse]

Nuts have been originally built for our desktop application.

Generating -delta packages required a different build process than the one we currently have:

• Current build process: (source code) -> .-full.nupkg | .exe
• Required build process: (source code + precedent releases) -> -full.nupkg | -delat.nupkg | .exe

So I started by integrating only full packages in Nuts. But we are open to PR to add an option to enable delta packages :)

[fasterthanlime]

Yep, generating delta is a bit expensive (have to download all previous releases..) thankfully our CI server does all of that.

I was just surprised you explicitly filtered it out! Seems like your desktop applications' RELEASES file should not even have any -delta nupkg in the first place?

I'll gladly submit a PR fixing that, already forked, will test & open later today