config key compat reminder

[Havoc Pennington <hp redhat com>]

Hi,

Mark just reminded me about forward/back compat for config keys.  If
users alternate between GNOME 2.0 and 2.2 with the same homedir, it
has to work. It might be worth thinking whether your app needs
emergency fixes in this area for 2.2.

If you:
 - added additional possible values to an "enum" gconf key
 - changed type or meaning of a key or directory without renaming 
   it
 - wrote code to "migrate" a setting, mangling the old setting 
   in the process
etc. then you may have broken things.

This policy is on http://www.gnome.org/projects/gconf/, I will append
the text from there to this mail.

If you have a bug in this area please let release-team know right away
and get it in bugzilla for tracking.

Havoc

Backward/forward compatibility

Here are the base rules:

    * Config keys must be backward AND FORWARD compatible
    * What this means is that if I log in from two places, using two
    * versions of an application, with the same gconf database, then
    * nothing should break.
    * To allow applications to add new features, we do allow that if
    * you are logged in using two versions, you may need to configure
    * "the same" thing twice, once per version. Of course it's best to
    * avoid this. 

To implement the rules:

    * If you in any way change the set of possible values of a config
      key, or how those values are interpreted, you must rename the
      config key.
    * If you don't rename the config key you can't add new possible
      values. The main case in which this will be painful is for
      "enum" config keys, where you add a new enum value in the code
      and have to change the schemas accordingly. 

If you rename a config key due to a change in possible values, you
could have your app copy the old key to the new key on startup, for
the case where the new key is unset. However it would be wrong to
delete the old key here (because the user may still use old versions
of the app simultaneously). You should only create the new key.

The reason why you need to be backward compatible is so that users
don't lose their settings when they upgrade the application
version. The reason why you need to be forward compatible is that many
times users share the same home directory for many different computers
running different OS versions or even different operating systems
entirely.