SyncEvolution 1.2: downgrade not possible, introduce config versioning

[Patrick Ohly]

Hello!

Since the beginning it was always possible to switch back and forth
between SyncEvolution releases. When backwards-incompatible on-disk
changes were necessary, the user had to explicitly asked for them with
the --migrate option (needed only once so far, to get the config layout
change).

For 1.2, this will no longer be possible, because libsynthesis changes
its on-disk format ("binfile") in a backwards-incompatible way (can read
old format, but old version cannot read new one).

On that occasion I also want to make several other changes which will
prevent going back:
     1. split "type" into independent options, to solve
        http://bugs.meego.com/show_bug.cgi?id=1023
     2. rename "evolutionsource" to "database", "evolutionuser/password"
        to "backendusername/password", with the old names accepted as
        alias, but not being written to disk

Here's how I intend to handle the transition:
      * Pre-releases of 1.2 will refuse to do anything with a config
        unless its complete context gets migrated with "--migrate
        @<context>"; this will also migrate all configs inside that
        context. The error message will explain this. Migration happens
        by renaming ~/.config/syncevolution/default to
        ~/.config/syncevolution/default.old and then recreating
        ~/.config/syncevolution/default with the new content. So it will
        be possible to go back, but only with slow or refresh syncs.
      * The final 1.2 will do the migration automatically, because most
        users (in particular those relying on a GUI) will have problems
        with the pre-release error messages.
      * I'll introduce .version files in ~/.config/syncevolution,
        ~/.config/syncevolution/* and ~/.config/syncevolution/*/peers/*.
        The content are two numbers, one specifying the oldest format
        definition that the directory is compatible with, the other
        specifying the current definition. Each SyncEvolution binary
        needs to check that it's current definition falls into that
        range, otherwise it is too old and cannot use the config. Using
        two numbers has the advantage that backwards-compatible
        extensions are possible.

The problem will be that SyncEvolution 1.1.x does not yet check that
version. After migrating the configs, it'll fail to find the "type"
property. I hope not too many users will fall into that trap.

Any comments? Implementation will commence soonish.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.