Add Sparkle for updating the app (Fixes #19)

[aaronraimist]

This initial version isn't automated. It requires a little bit of manual work on each new release but I think that is OK at least for now.

The first thing you need to do is download the latest version of Sparkle. It doesn't really matter where you put that. You'll have to provide the path to Sparkle to script I wrote.

Then generate keys for signing releases using Sparkles method since you aren't yet using Apple's code signing.

$ ./bin/generate_keys

Keep that private key safe and definitely make a backup of it somewhere. If you lose that you won't be able to update the app. Replace my dsa_pub.pem with the new one you just generated.

Then in the info.plist file change the SUFeedURL to a URL that you control. All you need to host here is the appcast.xml file.

I think that's all you need to do for the app to be able to check for updates.

How to create a new release:

Run the build_and_create_appcast script. You have to provide the path to Sparkle and the path to your private key.

$ ./scripts/build_and_create_appcast ~/Downloads/Sparkle-1.20.0/ ~/Development/seaglassWD/dsa_priv.pem

The terminal will output a signature that you need to copy into the appcast.xml file. See example below. You can remove the newline, not sure why Sparkle includes that.

Theoretically the signature should be the same on the Bintray build but I don't know that for sure. You may have to manually upload the .tar.gz that's in your build/ folder to Bintray if the signature doesn't match. Sparkle will show an error and will refuse to update if they don't match. Then you can link to that file in appcast.xml.

Example of an appcast.xml file with release notes: You could also provide a link to release notes, see https://sparkle-project.org/documentation/publishing/

<?xml version="1.0" standalone="yes"?><rss xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle" version="2.0">
<channel>
<title>Seaglass</title>

<item>
  <title>0.0.2</title>
  <description><![CDATA[
    <h2>New Features</h2>
    Support for:
      <ul>
        <li>Creating, joining and leaving rooms</li>
        <li>Accepting/rejecting room invites</li>
        <li>Redacting messages</li>
        <li>...</li>
      </ul>
    ]]>
  </description>
  <pubDate>Fri, 24 Aug 2018 21:06:32 -0500</pubDate>
  <sparkle:minimumSystemVersion>10.13</sparkle:minimumSystemVersion>
  <enclosure url="https://raim.ist/seaglass/Seaglass-65a6f5f.tar.gz"
    sparkle:version="203"
    sparkle:shortVersionString="0.0.2"
    length="10147320"
    sparkle:dsaSignature="MEUCIAPCaI/HQHc/bnoSVDqURrSZ38jj4GYGB83c07wYRByAAiEA1SBS5x/kLVV+fxrFhWHYgBDHu4VVcdG5F+gj1vz6qwA="
    type="application/octet-stream"/>
</item>

</channel></rss>

What that looks like in the update UI:

[aaronraimist]

Just listing some notes for my future self or anyone else who wants to try to fully automate it:

http://fauxpasapp.com/blog/2015/release-process

https://furbo.org/2011/03/09/mac-app-store-guide/

https://gist.github.com/huangyq23/668e6d6fcccf714e802a https://yiqiu.me/2015/11/19/sparkle-update-on-github/

https://github.com/coddingtonbear/taskwarrior-pomodoro/blob/master/createArchive.sh

[aaronraimist]

Sorry for all the extra commits 🤦‍♂️. Not sure exactly what I can squash without messing stuff up so I'm just going to leave it as it is.

[neilalexander]

So really I just need to come up with a suitable versioning scheme (which also unblocks #23) and then do we need to find somewhere to host the update file? Can we point directly to Bintray for that? I have an S3 bucket which might do the trick if so.

[aaronraimist]

You can just point at Bintray. Since it is also going to be a slightly manual process you could also upload it to the GitHub releases system but you don't have to rehost it anywhere if you don't want to.

[neilalexander]

I have to confess, I'm not enamoured at all with Bintray - it's not intuitive to browse and the reordering each time you reload the page to some non-useful order isn't great either. The problem with GitHub Releases is that they tend to need tags, which results in a lot of unnecessary stuff leaking back into the repository. Although I don't have a better idea yet... :-)

[aaronraimist]

Yeah I agree about Bintray. The way I use it is I look at the "Versions" section on the main page which are in order if I need to get an old version.

The way I was envisioning a new user getting Seaglass is that either they would download the latest release from the little Bintray badge in the README or from the latest GitHub Release (I'm not sure I understand your problem with it). Then they'll never have to use Bintray or GitHub Releases again since this PR will allow them to receive automatic updates.

[neilalexander]

Well GitHub Releases are of course fine for the big tags, i.e. v0.1, v0.2, but I don't think we want our CI pipeline feeding everything back into GitHub Releases or we'll end up with tags all over the place. As I remember it, GitHub Releases are a 1-to-1 map of tag to build. Happy to be corrected.

But agree that the automatic updates certainly make sense.

[aaronraimist]

No. I wasn't thinking of having all of that automated with GitHub Releases.

I was thinking a person could just manually tag and create the updates on GitHub Releases, only for actual versions v0.1, v0.2 etc not for every build.