Now Know When App Successfully Updates + Added Testing + Refactoring

[EliCDavis]

This diverges from what the current process looks like for using this library.

I got rid of certain things like the random update checking times and tried to make it simpler to set up.

This isn't complete, but I wanted to know if you would be interested in all these changes, or if you'd prefer to keep going with your current method for updating.

If you are interested, I'll clean up the rest of the documentation to match the new way.

[0cv]

@EliCDavis absolutely useful to me as I was looking for a way to trigger the update myself, instead of waiting on a timer. I still would like a way to be able to deactivate the patch thing, which is throwing errors while, it's expected (that there is no patch). And ideally a way to customize file names instead of simply darwin-amd64.gz. This doesn't tell much anything to non-tech people (as I use this place also for public download).

[EliCDavis]

Hi @Krisa, When you say "I still would like a way to be able to deactivate the patch thing, which is throwing errors while, it's expected (that there is no patch)." Are you referring to this repository or mine? I don't think mine throws any errors if there is no update to be made. https://github.com/EliCDavis/go-selfupdate/blob/master/selfupdate/selfupdate.go#L151

As for file names, you have a good point.

[0cv]

@EliCDavis I was referring to yours (albeit this original rep is the same too). It goes no matter what into the function getExeWithPatchForVersion https://github.com/EliCDavis/go-selfupdate/blob/master/selfupdate/selfupdate.go#L180 and it fails when it makes the query.

[EliCDavis]

I guess I'm confused about why it gets there. It's already had to do a fetch to determine if an update is available. If it got to that point that means there is one. I guess I'm missing something

[0cv]

Not so sure, but it looks to me expected. Then it goes to this line https://github.com/EliCDavis/go-selfupdate/blob/master/selfupdate/selfupdate.go#L192 as an error is returned and successfully update the lib. But hitting the patch URL in the first instance is the problem.

[0cv]

As for the file names, it could be an optional mapping when the function is initialised which tells which file correspond to which platform. For example

updater.SetPlatforms(&Platform{
    DarwinAmd64: "myosx",
    LinuxArm:          "linuxapp",
    Windows386:  "windowsApp.exe",
})

[sanbornm]

binaries and exes pushed to branch