Bundle Identifier ?

Since we now have our own "canonical" GitX, should we switch bundle identifiers ? I was planning to bring the Travis releases into the party, but we'd be stepping all over GitX-dev Sparkle feed if we did that so...

I don't think Sparkle locates the app by its bundle identifier, does it? I've never had trouble updating an app with multiple copies installed. Searching the code, it looks like it's only used to detect name changes and for the cache directory.

In any case, now is the best time to change the bundle id, and it's probably a good idea. io.github.gitx? Or io.github.gitx.GitX?

Works for me either way as long as it doesn’t inconvenience users too much. I guess a bundle ID change means

• a loss of preferences (not that much to lose with GitX as far as I can tell)
• a chance of AppleScripts being affected (probably when addressing the application as »app id "net.phere.GitX"«)

The latter makes me worry that this could break workflows. And what the advantages of using a distinct bundle id are.

Preferences could be migrated by reading the old preferences plist directly. Breaking AppleScripts is a good point against.

Keeping the bundle ID is only troublesome if one of the other forks that use the same ID become active again and diverge on OS features that rely on the bundle ID. File associations, URL schemes, preferences, QuickLook and Spotlight plugins, and AppleScript are ones I can think of off the top of my head. Code signing might track some state by bundle ID, though it might be smarter and also use paths and xattrs; I'm not sure.

Sparkle uses the URL in the bundle properties to check for updates. Existing builds will continue to check that URL for the update XML.

Pretty much nothing relies on the bundle ID.

On 18 January 2017 at 12:14, nanotech [email protected] wrote:

Preferences could be migrated by reading the old preferences plist directly. Breaking AppleScripts is a good point against.

Keeping the bundle ID is only troublesome if one of the other forks that use the same ID become active again and diverge on OS features that rely on the bundle ID. File associations, URL schemes, preferences, QuickLook and Spotlight plugins, and AppleScript are ones I can think of off the top of my head. Code signing might track some state by bundle ID, though it might be smarter and also use paths and xattrs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gitx/gitx/issues/18#issuecomment-273353074, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC3yS3dLREhfYgZ2wAguolWcq2_6Wklks5rTWdugaJpZM4Lj7U7 .

Wasn't aware of the Sparkle URL thing, so at least that clears it up. I was actually more concerned about confusing OS X (right now it's already confused by Debug builds when using gitx, because it sometimes prefer).

only troublesome if one of the other forks that use the same ID become active again

Yes, this is what I was afraid of, we'd have to start a war about "who LaunchServices deems the best version to use", and I don't want that.

The AppleScript support is a good point, but given the breadth of our sdef, I'd bet not many people have that much scripts around (I mean, come on, why use AppleScript when I could be bashing away :wink:). File associations I don't think we could ever grab folders back from Finder so that's a no, URL schemes would be a mess (dunno if we have one, I think we do, but it might be from an unmerged GitX-dev PR), preferences are not that bad, and QuickLook/Spotlight are not relevant (we don't have any).

This isn't really as big a problem as it seems; the majority of people will only have one GitX binary available for OS X to find, and whenever I had an issue it'd always found the most-recently-launched one.

Preferences should be semantically equivalent between forks, if so you'll get the "nice" side-effect of prefs sticking between builds, and if not it's probably a bug in one or both sides.

URL schemes and file associations are best managed by the user anyway, IMO.

On 27 January 2017 at 07:56, Etienne Samson [email protected] wrote:

Wasn't aware of the Sparkle URL thing, so at least that clears it up. I was actually more concerned about confusing OS X (right now it's already confused by Debug builds when using gitx, because it sometimes prefer).

only troublesome if one of the other forks that use the same ID become active again

Yes, this is what I was afraid of, we'd have to start a war about "who LaunchServices deems the best version to use", and I don't want that.

The AppleScript support is a good point, but given the breadth of our sdef, I'd bet not many people have that much scripts around (I mean, come on, why use AppleScript when I could be bashing away 😉). File associations I don't think we could ever grab folders back from Finder so that's a no, URL schemes would be a mess (dunno if we have one, I think we do, but it might be from an unmerged GitX-dev PR), preferences are not that bad, and QuickLook/Spotlight are not relevant (we don't have any).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gitx/gitx/issues/18#issuecomment-275511105, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC3yQkF_Lvi--NgZl3QsIbGY8NDmRB6ks5rWQiSgaJpZM4Lj7U7 .

it would be nice to have the latest gitx in homebrew, along with the latest release. so we should start making releases again.

We tried this during signing and notarization https://github.com/gitx/gitx/issues/278 But we run into

• https://github.com/gitx/gitx/issues/344
• https://github.com/gitx/gitx/issues/342
• https://github.com/gitx/gitx/issues/336

To be honest I would keep it like it is and close this. If you don't agree, please reopen it