On Wednesday, November 27, 2002, at 12:08 pm, Manuel Guesdon wrote:
I've found a problem using an application compiled with a previous
version of core/base (around
jully 2002).
A new application has modified ~/GNUstep/Defaults/.GNUstepDefaults
and make the
dictionary unreadable by the old application (sorry, I haven't kept
the modified file but it
was a number coded as 7200 in previous version now coded <*I7200> or
something like that).
It take me some time to guess why the application failed to run.
So is it possible to add versioning system in this kind of file so an
new application won't badly
modify this file when the file version is older ?
Or use different file names for incompatible version
(~/GNUstep/Defaults/.GNUstepDefaults.x.y) or something else.... ?
Unfortunately the plist format (the old one, not the xml one) contains
no provision for versioning ...
perhaps we should move to the new xml format for defaults?
Now, I have to make ~/GNUstep/Defaults/.GNUstepDefaults owned by
root, writable only by the owner
and readable by everyone (pplication fail to if it can't read the
file) so old and new application can run..
Unless you use statically linked applications, your old apps can just
use the new library and work with
the new format, so I didn't think this was likely to be a big issue.