>>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.