Sorry about that, folks.

• Added a new delegate method to SUUpdater.h to allow delegates to specify custom version comparators.
• Added a German localization, courtesy the Camino localizer team: Dominik T., Tobias Stohr, and Friedemann Bochow.
• Bug fixes:
  • Fixed a serious bug which could cause a server to be DDoS’d (or the host app to crash!) if an appcast fails to be parsed.
  • Fixed .tbz extraction if the archive was made with Stuffit.
  • Fixed support for .tar.bz2 and .tar.gz; Sparkle has to assume the archive is a tar when it sees “bz2″ and “gz”; don’t use those without tarring.
  • Fixed a typo which caused the shouldPromptForPermissionToCheckForUpdatesToHostBundle: method to not work in 1.5b2.
  • Fixed .zip extraction on Tiger (Apple changed the UTI between releases)
  • Fixed a crasher on Tiger.
  • Fixed display of the default app icon when the host app doesn’t have an icon.
  • Sparkle now displays a sensible progress string and uses an indeterminate progress bar when the server doesn’t report a file size.
  • Fixed some memory leaks.

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.h for 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 ppc64 by default. If you want to ship that, feel free to build your own, but this saves a few hundred k.
• 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's delegate an IBOutlet so you can hook it up in Interface Builder.
• 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

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.

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?

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.

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.

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

Contributing to Sparkle

The main reason I switched to Bazaar is that it’s now so easy to contribute to Sparkle. And, thankfully, it’s just as easy for me to integrate your contributions.

There are just a few steps you’ve got to do the first time you’d like to contribute:

1. Grab a Launchpad account. Launchpad will host your branches; it also keeps track of which bug[s] your branch fixes.
2. Head over to your profile and click the link on the left to update your SSH keys. This is how you authenticate to Launchpad. If you don’t have a public key, it’ll explain how to generate one.
3. Let bzr know who you are. Open up a command prompt and run:

   bzr launchpad-login YOUR_LP_USERNAME

4. Then make sure you get credit for your work with:

   bzr whoami "Joe Henderson <theemailaddress@yougavelaunchpad.com>"

From here, the average lifecycle looks very much like SVN’s:

1. bzr pull to get the latest code.
2. Make whatever changes you’d like to make.
3. bzr add foo.c bar.h to tell Bazaar about any new files.
4. bzr commit -m "Description here" to record the patch, OR if you’re fixing a particular bug, run this to link the revision to the bug:

   bzr commit --fixes lp:12345 -m "Description here"

If you do that a bunch of times, you’ll have a number of patches on your computer, but they won’t be on the server yet. To publish your changes, you make a branch. Here’s how:

bzr push lp:~YOUR_LP_USERNAME/sparkle/BRANCH_NAME

That’s it! You’re done! Your code’s online, and if you linked revisions to bugs, your branch will show up on the bug description page.

You can explicitly propose your branch for merging into the main branch: just login, find the branch in question on your profile, and click the proposal link on the navigation bar.

If you want to keep working with your branch, just run this every so often to merge in any changes from the main branch:

bzr merge lp:sparkle

You can read more about Bazaar in the great user guide on its homepage. And if you run into trouble, feel free to ask a question.

Well, it’s been a long time coming, but Sparkle 1.5 is finally available. Except it’s Sparkle 1.5b1. This means I think it’s done, and lots of people have been using it for a while, but it might still have rough edges.

There’s a new site, too, and it’s dramatically simplified. Documentation is… forthcoming, I’m afraid—if you want to use any of the really fancy new features, you’ll have to take a look at the code to see how to do it. Sorry about that. I’ll get to it in a few weeks.

I’m also actively soliciting localizations. All of Sparkle’s old ones are wayyyy out of date. If you’re interested in doing a localization, you should email me so that we can coordinate and not have many people doing one language.

What’s new? Oh goodness, tons of stuff.

• The most important things to know:
  • The 10.3 support is untested at best; sketchy at worst. Test with it thoroughly before you use it.
  • Sparkle now asks for permission to update on second launch; don’t be surprised at that. You can change that behavior with a delegate method; read SUUpdater.h for more info.
  • We no longer distinguish between “check on startup” and “scheduled updates”; everything is scheduled, with the default being every day.
  • The test application is using the new profiling features, but that’s only for demonstration: these are off by default. More on this later.
  • There are no localizations yet.
• New features:
  • Sparkle now supports .pkgs. Just name the .pkg the name of the app and put in the update archive.

  • Sparkle now sends optional demographic profiling information; set SUEnableSystemProfiling to YES in your Info.plist and check out the GET data sent to your webserver when fetching the appcast. More on this in the documentation. The test application has this on so you can see the behavior.

    This new feature—I foolishly neglected to mention—is courtesy Tom Harrington and the other Sparkle+ folks.

  • Sparkle now supports updating non-.apps. Just call -setHostBundle: on the global SUUpdater to let it know what you’re trying to update.
  • Sparkle now supports garbage collection in the host app. Use “Sparkle-with-GC.framework” for that, but be aware it’s 10.5-only.
  • Sparkle is now 64-bit compatible, compiling both ppc64 and x86_64.
  • Sparkle now supports a sparkle:minimumSystemVersion attribute on the enclosure. It does what you think it does.
  • Sparkle now checks to see if the host app is running from a disk image and refuses to update if it is. (10.4+ only)
  • Added support for entities in enclosure paths.
  • The file size output is now formatted prettily.
  • Sparkle now gives visual indication that it’s checking for updates when the update’s user initiated. ie: it pops up a status controller saying “checking for updates…”
  • Added support for an SUPublicDSAKeyFile, so people don’t have to copy/paste their entire key into their Info.plist. Set this key in your Info.plist to the filename of the key in your Resources directory.
  • Added an actually maintainable codebase.

• Changes:
  • Sparkle version comparison is now dramatically less stupid and verified by a bunch of unit tests. If something doesn’t work the way you think it should, add a test to SUVersionComparisonTest.m
  • Added a minimum to the check interval so that developers don’t accidentally release their apps into the wild with 60-second test check intervals and have DOS-attack-like results. It’s an hour now for release mode; feel free to change it.
  • The relaunching process now uses a separate helper app, which is a much more robust method.
  • Changed CFBundleShortVersionString behavior: Sparkle no longer uses Apple’s about box style of displaying ShortVersionString (CFBundleVersion) when the latter is available.
  • No more MD5 checking. Use DSA: it’s actually secure.
  • The abomination that was SUStatusChecker is dead. Use SUProbingUpdateDriver instead.
• Bugfixes:
  • Fixed a huge bug with fully-automatic updating: before, if the user chose to relaunch later, the app would be running from the trash for a while. Now the buttons are “install and relaunch” or “install later.”
  • Sparkle forces Spotlight to reindex the updated app so that it won’t keep pointing to the one in the trash.
  • Sparkle trims whitespace from around DSA signatures; this could cause crashes before.
  • Fixed a bug where the user choosing to skip a version would inhibit future automatic updates until the next launch.
  • Fixed a bug that could occur when the app has a localized CFBundleName.
  • .dmgs now work on Leopard.
  • The status controller’s button now sizes appropriately to the localization.
  • Sparkle now works correctly with LSUIElement apps: it focuses them before displaying the update alert.
  • Sparkle now deletes failed partial downloads.
  • The update alert no longer floats above everything in the app.
  • Fixed varied and sundry memory leaks.
• A ton of other things that I’ve forgotten or were too small to mention!

If you click some of the links along the right side of Sparkle’s home page, you might notice that they lead to some new places…

Sorry, Git lovers, my guts took me to Bazaar and Launchpad. It wasn’t really a Git vs. Bzr thing; it was a Launchpad vs. Lighthouse+Github thing. I’m really pleased with the new solution so far, and I hope you’ll follow me to new and maintainable horizons.

Sparkle’s development now has a new home, complete with a new source repository and a new bug tracker.

Soon-ish, I’ll get up a new, simplified Sparkle home page—one that doesn’t have four different nav bars—and wiki. If any of you lovely designers in the audience feel like contributing, I’d love the help. I’m also looking into enabling the translations and blueprints sections for Sparkle on Launchpad.

Update: Some people were saying they were having trouble getting Bazaar going on OS X. It’s actually pretty simple: just get MacPorts and run:

sudo port install bzr