Squirrel.windows: Common causes of ignored updates?

[markfox1]

For reasons unknown, without any real effort, I can get Squirrel into a state where it ignores any new updates. Once in that state, only running Setup.exe can get things moving again.

Could this be forgetting to increment the version number? This is something I am very guilty of, but I can't understand why Squirrel would ignore future versions because of this. No doubt there is an exception being thrown and my code ignores it. Splat logging to the rescue.

If forgetting to change the version is a problem, it might be worth a note in a "traps" section of the documentation.

[anaisbetts]

Could this be forgetting to increment the version number? This is something I am very guilty of, but I can't understand why Squirrel would ignore future versions because of this. No doubt there is an exception being thrown and my code ignores it. Splat logging to the rescue.

Yes, Squirrel for sure will not do an update if the version numbers are equal. Gotta change it!

[markfox1]

I should have been more clear, but thanks for attempting to make sense of my blather. Here is how I (seem) to get Squirrel stuck:

1. Version X.Y.Z is running great.
2. I make a modification and build a new release without modifying X.Y.Z.
3. I place the new files making up the release in the place that the program will look for updates.
4. When I run the program, no update is done.
5. I slap my head.
6. I increment the version to X.Y.Z+1, build a new release, and again place the necessary files in the right place for Squirrel to find them.
7. The program still doesn't notice any new files for an upgrade.
8. If I make still more releases, incrementing the version each time, it doesn't notice them.
9. Running Setup.exe gets things back in order.

I'll be instrumenting my code with Splat logging this morning. Hopefully that sheds some light on my mistake.

[markfox1]

A bit of thinking about how Squirrel works makes it clear why forgetting to increment the version bungs updates, even after correcting the problem:

If I have version X.Y.Z installed out in the wild, then build a new release without changing the version, the new RELEASES file will no longer know about the installed version. Since deltas between versions are generated, the update chain is broken forever.

I suppose Squirrel could just choose to grab the latest full package when this occurs. In the meantime, I'm removing myself from the loop and figuring out how to have MSBuild automatically increment the last version number after every successful release build.

[JKSnd]

IMO, the releasify process should detect when the nupkg being releasified has the same version as an entry in the RELEASES file, and fail. This is a developer error, so I think it should be handled as such.

[JKSnd]

@markfox1, If you're using a Git-flow style of branching, we at PK Sound use a pre-build script that automatically versions our assemblies and exe's based on branch name and most recent tag. We even package the script in a NuGet package so installation is super easy.

If you're interested in help with automating this, I can clear it with the rest of my dev team to publish our library. Let me know if you're interested.

[markfox1]

@JKSnd Completely agree that releasify should fail if the versions are identical.

I'm interested in anything that could protect us from breaking our released delta chain. That would be particularly embarrassing and result in losing a couple of days to phone calls. I think it may be as simple as letting MSBuild choose the version by setting it to X.Y.*, but I'm only fifteen minutes into this.

I feel the pain the most when debugging or testing something that requires an installed version of our software. Then my work-flow just repeats incrementing the version, modifying the code, building, and installing. It's just too easy to forget to increment the version when focused on a bug. Then I end up doing an install (setup.exe) and, since that wipes any settings that may exist, I end up running through our programs setup "wizard", which adds a couple of minutes to the work-flow.

[JKSnd]

I feel you on that pain. As I mentioned, we use a git-flow style workflow. This allowed us to have our CI server invoke builds in different configurations depending on what git branch is being built. Builds on our develop branch use a configuration that tells squirrel to use a different releases URL than production, and our server deploys those builds to a beta server. Builds on master are created and deployed to a production server. It works out really well, and our workflow involves nothing more than merging pull requests.

[JKSnd]

Hey @markfox1, have you checked out GitVersion? I'm likely to migrate toward it in my build scripts (which are Cake btw, which is awesome).