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 _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
