>>Having the version number in the app has other benefits as well such as opening a file your app creates. If your formats may have changed over time, you can easily check the version number to see if a certain file format can be used.<< I've always maintained two _separate_ version numbers. One, visible to the user, lives in the "vers" resource and changes to reflect changes in user interface-- 1.0.1 is a minor tweak, 2.0 is wholesale revision. It isn't used internally at all. The second, stored as a "gameVersion$" variable, changes incrementally ("002" to "003") each time I make _any_ change that affects saved games. (Yeah, OK, it can apply to any app that creates files. Games just happen to be what I do.) This string is the first thing written to, or read from, a saved game, and it affects how the rest of the data is handled. That way, any game created from an earlier version of the app can still be read correctly in a later version that uses slightly different variables. Now, the part that only recently occurred to me: If the app reads a saved file with a gameVersion$ that's _greater than_ the current version string, it ought to put up a special alert saying "This file was saved in a more recent version of ___, and I may not be able to read it correctly". This isn't a very common scenario in games, but it happens all the time with, for example, word- processor files. Just imagine how much distress and misunderstanding would be saved if StuffIt put up this message whenever it came face to face with a newer file format.