Sparkle updates

[willwhite]

We can host an appcast on gh-pages. We may have to change our CFBundleVersion so it uses an actual number instead of a hash. Hashes don't have an order, and Sparkle uses them to determine if the user's version is older than the current version.

Sparkle will also uses Shared User Defaults to keep track of whether the users has opted for automatic update checks, so this is related to #584.

[incanus]

This is coming together in the Sparkle branch.

Code is essentially done; issues remaining:

• Storage & sharing of private key outside of repo.
• Location & maintenance of appcast feed. /cc @willwhite
• Location & maintenance of binary versions. /cc @springmeyer
• Revision of build version script.

[incanus]

Also, I'd argue against allowing automatic updates via Sparkle; that is, we only allow users to consciously update their application after being prompted, versus allowing them to check a box that could potentially auto-update their app on app launch following a new version release. I think this is potentially disruptive to the user workflow, plus we want users to see what's new in each version and allow for some communication there.

[springmeyer]

great work!

[willwhite]

App cast feed can live in at http://tilemill.com/platforms/osx/appcast.xml. We can just commit it directly to the repo and merge over to gh-pages. The feed should just point to the binaries we have hosted on the github downloads page. Does that sound ok?

[incanus]

@willwhite, I think those will work perfectly. Thanks.

[incanus]

For anonymous system statistics collection (which we can automate with Sparkle), we'd need access to our appcast's log hits, including query string. Can we get that @willwhite?

[incanus]

More re: stats collection: https://github.com/andymatuschak/Sparkle/wiki/system-profiling

[willwhite]

No we won't have access to this info since it'll be hosted on github.

[incanus]

Ok, I think the stats would be useful -- thoughts, @springmeyer? This is the kind of info we'd get:

One solution here might be to make a static appcast file on some site we do have stats on that does a redirect to the GitHub page. Then, we can collect the stats from our own logs.

[incanus]

Looking into this a bit more, and evaluating Feeder, which I've always used for appcasts in the past, it probably makes sense to work on a set of scripts for updating the appcast in-place, then allowing that to be pushed with gh-pages. Couple reasons:

• We'd need a Feeder site license or multiple licenses.
• We'd need to share Feeder config.
• It'd be handy to just automatically determine the download file name based on baked-in version number.
• We could have a DSA private key default (relative, for example in the top-level folder) location for signing appcast entries, but also allow some arbitrary path to be supplied if the user who's building desires it.
• We can automate the pointing to a version page or an anchor on a multi-version page based on version number to supply the changelog content.

So invocation would look something like this:

appcast.sh [-v version] [-k /path/to/dsa_priv.pem] [-c <changelog url>]

Or, more easily, for something like v0.5.0, just run appcast.sh and have the version & changelog URL auto-configured and default to the top-level folder for the private key.

Either case would export to platforms/osx/appcast.xml and get published via gh-pages.

Thoughts?

[incanus]

Some options to explore:

• http://www.entropy.ch/blog/Developer/2008/09/22/Sparkle-Appcast-Automation-in-Xcode.html
• https://github.com/CraigWilliams/appcastautomation
• http://blindgenius.wordpress.com/2010/01/16/sparkle-appcast-automation-in-xcode%C2%A0update/

[incanus]

Ok, first cut of the script is up. Still need to do some testing, but as of now, running platforms/osx/sparkle.sh does the following:

1. Gets the latest local tag (e.g., 0.4.2).
2. Confirms version with user before proceeding.
3. Makes sure entry for version exists in CHANGELOG.md.
4. Renders the Markdown out & updates the local platforms/osx/changelog.html.
5. Downloads the latest zip file (e.g., https://github.com/downloads/mapbox/tilemill/TileMill-0.4.2.zip).
6. Gets the byte size of the file.
7. Generates a DSA signature of the file using a local public key and a private key from the user's OS X keychain.
8. Updates the local platforms/osx/appcast.xml with download URL, signature, size, date, and HTML changelog.
9. Instructs the user what git actions to perform to update the remote appcast via gh-pages.

After more testing, I'll also create a doc for users for initial setup.

[incanus]

There's now a SPARKLE.md file with setup & usage instructions for devs. @springmeyer & @willwhite, please have a look when you are able and let me know what you think.

[incanus]

Specifically, a test would consist of:

• Assuming a test on 0.4.2 (for now).
• Running platforms/osx/sparkle.sh.
• Receiving a platforms/osx/appcast.sh that looks sane. This should also create a changelog.html, which in future versions will just get updated and pulled inline to the appcast.xml from the app's Sparkle WebKit.

[willwhite]

Cool! I will test this once I get my Mac OS X build working (#649).

[willwhite]

A few things here.

• In the Update Schedule dropdown box, I'm see two checkboxes https://skitch.com/diggersf/furxq/fullscreen.
• Can we add an "Check for Updates now button"?
• Should remove the system profile stuff and make this cleaner since we aren't able to use it right now?

[incanus]

@willwhite, thanks for the feedback.

• Checkmarks: shouldn't be happening; I'll look into it.
• We do have a main menu entry for this (TileMill > Check For Updates...), so you mean a button in the preferences?
• I think if we are eventually going to use it, we should ship with it at the start. Otherwise we have to re-prompt existing users to get the approval and that could be annoying.

[willwhite]

Weird with the checkmarks, huh. Sounds good on points 2 & 3.