Exciting news: Adam Radestock has taken up the gauntlet for SparkleCaster and has a preliminary version available! You can get more information and download it here.
Status report!
Meanwhile, I’ve frankly gotten nothing done on Sparkle since classes began again. Schoolwork eats all time, and even when it doesn’t, it eats all energy. On the bright side, my course in discrete mathematics is coming in handy for the new branching system based on posets. I have a nice algorithm in mind for solving some special case releases.
One particularly mean test case I’ve been considering is that of Dave Watanabe’s Inquisitor. The path from 1.x to 2.0 was a paid upgrade, but 3.0 was free for everyone. Obviously, users of 1.x shouldn’t be prompted to pay for the upgrade to 2.0 before getting 3.0 for free. That’s tricky.
In another tricky case, imagine a developer who is preparing for a 2.0 launch. They give out 2.0 beta builds to a small group of testers and provide upgrades to those beta versions via Sparkle. The users in the main branch never see these updates because they’re not connected to this branch. But when 2.0 final comes out, the developer wants to give his testers a free upgrade as a way of saying thank you. The normal 1.x users, however, are expected to pay. Tricky. I think I’ve got it, though.
The other guys
Software update is a trickier thing than it should be. It’s a silly, small, tiny problem that really shouldn’t be occupying this much time or attention. But if you think I’m sweating the details, you should see Apple’s implementation.
They download and execute Javascript files like this one for each update available; the scripts provide functions the software update client can call to determine whether the update should be displayed and how it should be installed. If you ever wondered why the “checking for updates…” progress bar took so long, that’s why.
On another interesting note, it seems that the software update client can be configured to use another server’s URL. Like maybe localhost. Intriguing. A tiny webserver could be run on users’ machines to serve update catalogs to localhost, thereby providing a unified update interface for Apple’s updates and 3rd-party updates alike. I’ll have to investigate this further.
The Conversation {1 comments}
Thanks for the status report Andy. Very interesting on how Apple do their software updates.
Leave a Comment
You can follow any responses to this entry via its RSS comments feed. You can also leave a trackback if the inclination is there.