Re: Implications of changing an app's bundle identifier
Re: Implications of changing an app's bundle identifier
- Subject: Re: Implications of changing an app's bundle identifier
- From: Darkshadow <email@hidden>
- Date: Sat, 24 Feb 2007 21:16:00 -0500
On Feb 24, 2007, at 8:29 PM, Daniel Jalkut wrote:
It might be worth considering that in some instances, the user
could be likely to run an older version of the application after
running the newer version. For instance, what if they were trying
out a new version but decided after running it once to stick with
the older version.
In this case, they would find all of their preferences "lost" and
with no obvious way to get them back.
I've been thinking about this lately, too. I think the best thing
might be to add a pref to the new preferences
"DidMigrateOldPrefs" ... if it's set, don't do anything. If it's
not, just copy the old prefs over but leave them around.
Daniel
Hmm, you have a point.
I haven't had anyone email me about this, though, and I did this
change for two of my apps back in August. One of them (Pref Setter),
had a few crashing bugs after that release, so users could have
downgraded. Though to be honest, Pref Setter's preferences would
only take all of two minutes to set back up, and they just may not
have felt the need to email me about it.
I don't know about leaving files around after this, though. I've
always felt like that's bad housekeeping on my part, to leave unused
files around on the user's system. Doing what you suggest, but
deleting the old files, would work. If they felt the need to run an
old version, they'd have to reset the preferences for it, but then
those wouldn't overwrite the new ones if they reused the new
version. They also wouldn't be deleted, then, but in that case it'd
be more on the user for having done that.
Heh, and I can see why you would be thinking on this, Daniel. ;)
------------------------------------------------
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden