andymatuschak.org: Sparklings

Okay, so it’s sounding like the risk and work involved in my last proposal outweigh the benefits.

I don’t want to spend a ton of time doing crazy things for Sparkle, anyway—I want to solve the software management problem correctly. Hrm.

On the bright side, 1.5b2 tomorrow, probably.

Sparkle is the wrong way to do software updates. This is for many reasons, but one of the big ones is that we’ve got tons of copies of Sparkle running around the system, some potentially very outdated.

Even without security issues, it’s silly to have some apps presenting new Sparkle interface and some apps not. And Snow Leopard compatibility weighs heavy on my mind.

I’ve said this whole time that really solving this problem is not something third-party developers can do. Software update is a small part of the larger software management problem, and I don’t think it can be solved outside of Cupertino.

This might help, though.

The Big Idea

Apps which use Sparkle would ship with a Sparkle stub framework. This would be comparatively small and hopefully require only rare changes.

After it asks “do you want to check for updates?” the stub framework checks to ensure the full Sparkle framework is installed and up to date (by fetching an appcast from my server). If either criterion is unfulfilled, it’ll fetch the latest Sparkle.framework and install it in ~/Library/Frameworks (so as to avoid authentication).

Then it’ll load the framework from that path and proceed as usual, checking for updates to the system framework perhaps once a week. I envision appcasts specifying that they require a particular version of Sparkle for non-compatible new features.

Obviously, there are a lot of issues and cases to take into account (including the fact that I’m not sure I want to do this much work), but I think this is the best solution for the immediate future.

Thoughts?

I just wanted to plug a couple of tools now available for automatic appcast creation.

The first is SparkleCaster, a Cocoa app by Adam Radestock. I’ve mentioned it on here before, but it’s made some progress—check it out and see if it fits your needs.

The second is new: a tutorial on using Rake to make appcasts. This is the kind of badassery that keeps me using Ruby.

Keep on rocking, folks! 1.5b2 soon.

For those wonderful prospective localizers, you should know that I’ve actually already changed a few strings since 1.5b1 (doh!). One of my localizers pointed out some flaws.

Anyway, here’s a new English strings file and test app to use to test with: Sparkle 1.5b1 Localization Pack.

I may need to update things some more if there are more problems; I’ll update this entry if that happens. Alternately, you can keep abreast of changes in a much easier (for me, at least) way using Bazaar.

I’ve got Sparkle 1.5b1 out, but unfortunately, I don’t have time to write the documentation or any of the supporting material at the moment.

This is kind of a problem.

So until I get a chance to do that, following is a brief guide on using Bazaar to contribute to Sparkle.

Getting the Source

First, you’ll have to get Bazaar. The easiest way to do that is to grab a .pkg from the project homepage. MacPorts is more trouble than you want to deal with.

Now, here’s all it takes to get a fresh copy of Sparkle’s code:

bzr branch lp:sparkle

continued…