Open Bug 445629 Opened 15 years ago Updated 4 years ago

Land Sparkle 1.5 once it's done

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: stuart.morgan+bugzilla, Unassigned)

Details

(Whiteboard: l10n)

Attachments

(1 file, 1 obsolete file)

preliminary landing, v2 [landed]
6.66 KB, patch
mikepinkerton
: superreview+
Details | Diff | Splinter Review 
We have a snapshot of Sparkle (r246) that corresponds to about 1.5b4; presumably there will be bug fixes in a final version before we ship Camino 2.0 that we'll want to snag.

I expect that it will be pretty easy, since the major structure seems to be pretty stable at this point.
We'll have to re-apply the changes noted in the README when this happens (bustage fixes that diverged us from r246).
Hardware: PC → All
The other thing we'll want this for is to get translations as they come in to Sparkle, since the big Sparkle re-architecture obsoleted all the old translations. Even some of what's there now seems to be a bit off already.
Flagging this for a1 for completeness and for a reminder to move to the next milestone flag.

However, based on our last conversations, Stuart owes Andy a patch for bug 426015 comment 12, and then Andy has to decide 1.5 is done (which may mean n completed l10ns, all of the old versions of which were obsoleted in 1.5), so probably not going to see this in a1.
Flags: camino2.0a1?
I'm in the processing of doing the upstreaming. Once that's done, I'll grab a new snapshot and test that things still work out, and we can land that for a1 so we are tracking closer to the final version.
Assignee: nobody → stuart.morgan+bugzilla
(Note to self: test 10.4 build this time)
Whiteboard: l10n
Attached patch preliminary landing (obsolete) — — Splinter Review 
Sparkle 1.5 is very close to final, so I'm grabbing the current version now so that a1 is as close as possible to what we will be using in 2.0 final.

Unfortunately, this pull made our integration with Sparkle uglier. All the prefs are now technically private, which makes our trick for disabling updates in unofficial builds without affecting release builds not work. Rather than completely restructure it yet again, I'm just cheating and using the raw keys where necessary. (We control the updating of the framework, and the keys are really unlikely to change in future versions anyway, so there's no real risk.)

I'll land the Sparkle update itself at the same time.
Attachment #339613 - Flags: superreview?(mikepinkerton)
Missed a file in the last patch.
Attachment #339613 - Attachment is obsolete: true
Attachment #339727 - Flags: superreview?(mikepinkerton)
Attachment #339613 - Flags: superreview?(mikepinkerton)
Comment on attachment 339727 [details] [diff] [review]
preliminary landing, v2 [landed]

sr=pink
Attachment #339727 - Flags: superreview?(mikepinkerton) → superreview+
Comment on attachment 339727 [details] [diff] [review]
preliminary landing, v2 [landed]

Landed on CVS trunk. I'm pretty sure I got everything from the Sparkle merge into CVS correctly.
Attachment #339727 - Attachment description: preliminary landing, v2 → preliminary landing, v2 [landed]
Moving to b1 so we remember to re-evaluate.
Flags: camino2.0b1?
Flags: camino2.0a1?
Flags: camino2.0a1-
-ing for b1, since Andy said recently he's guessing late December for a final release. Nothing has changed since our last snapshot and he's considering it essentially frozen except l10n, so we are in good shape for the beta.
Flags: camino2.0b1? → camino2.0b1-
Stuart, where are we on this?  We have r318 in cvs, and the current launchpad revision appears to be r340.  It looks like there's been at least one strings change since then, in r334.

We probably need to look at this again before b3 and make-it-so at that point.
Flags: camino2.0b3?
Updated to r343, with one temporarily local change for 10.4 SDK support (I've kicked off the process of upstreaming it).

Mostly it was l10n changes, but there were a few code changes--including a change to how updates are downloaded--so we should stay vigilant.

We'll keep watching, and if there are any more l10n changes before we spin b3 I can grab those.
Stuart said in bug 458757 he wanted to sync up again before we do b3, so nominating so that it stays on the b3 radar.
Flags: camino2.0b3?
Yeah, I almost did this yesterday before remembering that the tree is closed :P
Bumped to 349 on CVS trunk.
Flags: camino2.0b3?
Nothing relevant to us has landed since 349, so it looks like that's a wrap for b4. I'll keep on checking from time to time.
Flags: camino2.0b4? → camino2.0b4-
I thought it looked like something related to nibs had landed recently there :(

Also, note that we're trying to get l10n to make sure they have no issues with the "Status Text (set by  loc. string in code)" text field in SUStatus.nib, since that nib is outside of the lproj folders and does not appear to have any resizing code backing it: http://mozdev.org/pipermail/caminol10n/2009-August/002687.html 

Now that everyone is comparing the correct strings to the space, it looks OK, but we've only heard from a few l10ns so far.  Guesswork sucks, though ;)
Looks like there has been some recent activity, so I'll sync up again.
Stuart landed e7435964a2654b2e89fd1eafbe229dd7123417f6 earlier today.
Updated to 7bfbe83d87a88d106a935858a569414132b01614.
Chris discovered yesterday that the version we have contains the bug where Andy let Clang creep in, so Sparkle's not buildable out of the box in Xcode.
Wait, that error was removed back in July: http://github.com/andymatuschak/Sparkle/commit/e423cfee35bf11af6262a55a4632e8922c21c7be

I'm confused.

There's no clang in the Sparkle.xcodeproj at "master", but there is in our version in mxr.

Oh, it was reintroduced here in June by August: http://github.com/andymatuschak/Sparkle/commit/f2a7b4b349c52ea366d11183ef041d454025ad93

And not fixed until Andy's September 20th commit: http://github.com/andymatuschak/Sparkle/commit/af37928283042f985e6c7c6ce67869de74e39b52
Updated to af37928283042f985e6c7c6ce67869de74e39b52 (unfortunately with a butchered commit log, thanks to a misplaced -m)
Since we are in the final stretch and things have been quiet in Sparkle-land for almost a month, I'm going to go ahead and take this off of the 2.0 list. If something important comes up we can still grab it, but it's probably not worth polling all the time any more.
Target Milestone: Camino2.0 → ---
Assignee: stuart.morgan+bugzilla → nobody
(In reply to bug 560985 comment #3)
> (In reply to bug 560985comment #2)
> > Sounds like we should do another refresh from Sparkle trunk at some point.
> 
> Yeah, assuming it still compiles on 10.4.  Andy just landed delta-updates last
> month; not sure what sort of instability that might have introduced.

https://bugs.launchpad.net/sparkle/+bug/556303 says that 10.4 support is broken after delta-updates, so we'll want to see how that shakes out.

(That also makes it sound like we could pull everything pre-delta-updates and get 6mos worth of fixes "safely", at least wrt running on 10.4; we'd still have to check building on 10.4 and integration issues.)
I updated to the current trunk, bypassing the currently-10.4-breaking delta stuff, in both hg (3094:65d327762d19) and CVS trunk.
3095:ae7de8a83c18 landed (and the same on CVS trunk) to fix 10.4 bustage.
So, Andy took a fix that weak-links libxar (and which does some libxar-availability checks) to unbreak 10.4 support:
https://bugs.launchpad.net/sparkle/+bug/556303
http://github.com/andymatuschak/Sparkle/commit/454822823831818aef29826adebd7a43d2ac725a

Unfortunately, the fix requires Xcode 3.2 for weak-linking support, which means Sparkle just jumped from being buildable on 10.4+ pre-delta-updates to only being buildable on 10.6 :(

So it looks like we're going to have to continue branching around that indefinitely :(
New-style weak-linking (by just toggling the "Role" column) starts in Xcode 3.1, not 3.2  Someone on 10.6 should download a Sparkle tarball and set the project compatibility to Xcode 3.1 and see if Xcode warns about anything else, though.

Old-style weak linking has been supported since at least 2006 (per the date on the document): http://gemma.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html#//apple_ref/doc/uid/20002378-107026

I don't know if Andy would take a fix that switches back to old-style weak linking, or if we should fork that in our copy of the project, or if we don't care as long as we don't have to take any more fixes.  (From a philosophical point of view, I dislike the fact that Sparkle 1.5 went from being buildable on 10.4 to requiring 10.6 just like that, but I also have a philosophical dislike of adding a major feature long after the "last" beta, and the coding style, and not testing both release and debug if one is missing "warnings-as-errors", and all sorts of other things ;)  But Sparkle is not my project ;) )
You need to log in before you can comment on or make changes to this bug.