Re: GConf Key Reference



On Sun, 2006-05-21 at 12:05 -0600, Brent Smith wrote:
> 
> > Unfortunately, a lot of cases of backwards-compatibility breaks
> > (and forwards-compatibility breaks) just won't be detectable with
> > any sort of script that I can think of, and that would be really
> > nice data to have.  (Not so that we can adjust for it, but so that
> > we know it's time to smack a developer.)
> 
> Why wouldn't it be detectable?
> 
> We should be able to detect new keys for every distinct "owner", as
> well
> as removed or deleted keys.  We should also be able to detect new
> owners, and changes in keys types and default values.  Can't think of
> anything else that would change that would break things...

So let's say there's an integer key that specifies
how many seconds to wait for something.  But then
somebody decides we should let you set how many
milliseconds, so they change the meaning of that
key.  That would be a compatibility problem.

Granted, the default would very likely change for
that.  But then, not all changes in defaults are
compatibility issues.  Sometimes we just change
the default, and that's ok.

For a more subtle example, consider a string key
that's a "magic" value, essentially a value from
an unspecified enum.  If a new version of your
application recognizes a new value for that key,
you potentially create a problem with forwards
compatibility.  My gconf settings might be in
my home directory on NFS (like they are at work
for me).  If I use the new value in Gnome 2.X
on one machine, my settings get all screwy in
Gnome 2.(X-2) on another.

--
Shaun







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]