Alright folks, it’s been a few weeks, and we’ve gotten a ton of bugs hammered out. If you’re using 1.5b1, you should absolutely upgrade to b2, as a number of somewhat critical bugs have been fixed.
As of this writing, there are no known bugs (other than Sparkle being bigger than I want it to be), so please let me know if you find something amiss.
Still no documentation yet, but now that the bugs are closed, I’ll get on that.
What’s New?
- Compatibility Issues:
- Most of the delegate method selectors have changed to scale better. See
SUUpdater.hfor changes; you’ll likely have to make changes if you implement any delegate methods. - If you’re using .tar.gz or .tar.bz2 archives, name them “.tbz” or “.tgz” instead; Sparkle now uses UTIs for archive detection, and it’s not smart about double extensions.
- I’m no longer supporting 10.3. This may or may not work on Panther—probably not.
- Sparkle’s no longer built for
ppc64by default. If you want to ship that, feel free to build your own, but this saves a few hundred k.
- Most of the delegate method selectors have changed to scale better. See
- Enhancements:
- Sparkle now detects if the preferences for automatic update checks or the time interval change mid-cycle. If your product is a non-.app, you need to clue Sparkle in on the change by calling
[[SUUpdater sharedUpdater] updatePreferencesChanged]. - Added a cancel to the “checking for updates…” dialog.
- Sparkle now cleans up all its litter in /tmp.
- Made
SUUpdater'sdelegate anIBOutletso you can hook it up in Interface Builder.
- Sparkle now detects if the preferences for automatic update checks or the time interval change mid-cycle. If your product is a non-.app, you need to clue Sparkle in on the change by calling
- Bug fixes:
- Sparkle no longer crashes on non-GC hosts when the user cancels an update’s downloads.
- Sparkle no longer gets stuck in an inconsistent state or crashes when it can’t parse the appcast on scheduled updates.
- Added the sharedUpdater method to
SUUpdater, as it should have been. - Fixed a bug where the “checking for updates…” window wouldn’t go away if an error occurs while checking for updates.
- Made the dual-mode build configuration actually use the .xcconfig which builds it with GC support. (oops!)
- Fixed relaunching for prefpanes.
- Sparkle no longer fails to install updates on Snow Leopard (though there’s still an issue with trashing the old version of the app, but it seems to be a 10.6 bug)
- Sparkle now handles redirects correctly under Tiger.
- Fixed the installation path for non-.app bundles.
- Fixed a bug which could crash Sparkle under non-English locales.
- Fixed a weird race condition which could cause the relaunch tool to never notice that its target relaunched.
- Fixed a bug where if the host app is inactive when an update occurs, the update alert sometimes doesn’t become key.
- Minor textual fixes.
- Localizations:
- Dutch, courtesy Maarten Van Coile
- French, courtesy Yann Ricquebourg
- Spanish, courtesy Ernesto Gomez Cereijo
The Conversation {6 comments}
Congrats and a big THANKS for your hard an ongoing work!
Thanks for all your efforts. I look forward to trying 1.5b2 when I get home from work today.
Excellent stuff Andy! I’m looking forward to rolling this in later tonight.
> If you’re using .tar.gz or .tar.bz2 archives, name them
> “.tbz” or “.tgz” instead; Sparkle now uses UTIs for archive
> detection, and it’s not smart about double extensions.
That qualitifies as Most Stupid Change :-( .tar.something is standard naming, it’s *much* more common than .tgz etc.
On a somewhat related note, it would be nice to support .tar.lzma too…
Thanks for the kind words, folks!
Sorry about the .tbz/.tgz thing. I know it’s dumb, but I wanted to switch to UTIs because they (in theory!) are more robust. Harrrumph. LaunchServices gives me what it gives me; I haven’t figured out a way around that yet. I’d welcome a patch, though, if you have any ideas.
Perhaps use compiled nibs (generated from xib files) - might save a little bit of space, especially with a lot of localizations. Only tradeoff is that they cannot be modified from within the app, but that shouldn’t be much of a problem.
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.