426015 - Update to a newer version of Sparkle

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Stuart Morgan]

We need to get onto a newer revision of Sparkle if we can find something we trust to be reasonably stable. At that point I'll probably need to rework some of our Sparkle interactions, as the update check interval model was changed in Sparkle (to be more like what we currently do, IIRC).

We should try to get Andy to land our all our changes so that we can at least start fresh and unforked. Of our trunk changes:
- XML handling landed
- Bundle version display landed
- Quarantine hasn't landed
- The empty feed URL I don't think we submitted, but I'll see if that's still necessary in the new code first.

Comment 1

[Stuart Morgan]

I've emailed Andy about quarantine (Ticket 151)

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #1)
> I've emailed Andy about quarantine (Ticket 151)
 
Andy landed this as revision 142 on Sparkle trunk: http://sparkle.andymatuschak.org/changeset/142

Comment 4

[Stuart Morgan]

Flagging 2.0a1?, since I think we'll want as many update cycles as possible with a new pull of Sparkle so we can shake out any new issues.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I do think this should block a1 for that reason, assuming that the updating doesn't push us too far back.

Comment 6

[Stuart Morgan]

I made a few Sparkle changes we need before we can cut over, and sent them off to Andy as lp:~stuart-morgan/sparkle/camino-fixes. I'll hold off on posting the Camino side of this for now, as there may be updates to the fixes I made that would require different changes in our code.

Comment 7

[Stuart Morgan]

Attachment: camino changes

Andy has landed changes that handle the pref-change watching that was the last piece of missing functionality we needed (better for our needs than what I sent him), so the Camino changes should be stable now. Things are a lot simpler for us in the Sparkle-1.5 model, so it's mostly removal of code. Launching an unofficial build will no longer disable updates in a running official build, which will be really nice for us.

We still need warnings fixed in Sparkle (r160 in my branch), and I've emailed Andy about getting those merged. Once they are in, we can land a pre-1.5 snapshot for 2.0a1, and pick up fixes from the Sparkle trunk periodically leading up to our 2.0 and Sparkle's 1.5.

Comment 8

[Mark Mentovai]

Comment on attachment 327364 [details] [diff] [review]
camino changes

Fix the plist indentation and keep the keys alphabetized.  I have a bug up my butt about that.

The app.update.url wasn't hardcoded in the js.in file for two reasons: to make it easy to turn off during the build (which you've accounted for) but also to make it easy for third-party builds to provide their own feed.  Can we leave APP_UPDATE_URL in place?

Otherwise, this looks good.

Comment 9

[Stuart Morgan]

Attachment: camino change, v2

This puts back the current url stuff, and adds some framework twiddling since Sparkle switched to @loader_path sometime recently.

I'll land a current Sparkle snapshot with this (and update the readme), since the Sparkle tree is in good shape for us now.

Comment 10

[Stuart Morgan]

Landed on trunk, along with the new Sparkle snapshot (have I mentioned how much I love trying to do updates to a whole directory structure under version control?).

I filed bug 445629 to remind us to get the stable version down the road.

Comment 11

[Stuart Morgan]

Sigh, I didn't try compiling Sparkle on Tiger. Initial build bustage fix checked in (Spakle's config files use the new FOO[arch=bar] syntax, which our toolchain doesn't support), and I'll compile on Tiger now and get any other bustage fixes checked in ASAP. Doing a backout would be painful enough that I'll avoid it if possible.

Comment 12

[Stuart Morgan]

String literal bustage fix checked in; I'll try to push that one upstream.