Bug 1070744

This has to be fixed in 7.0, because developers will probably rebase Evolution to 3.10 in 7.1.

(In reply to Martin Holec from comment #0)
> This can cause trouble to users when they upgrade to 7.1
How does downgrade from evolution 3.10 can cause problems to 7.1 users?

devel_nack - We don't support downgrading.

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

(In reply to Matthew Barnes from comment #3)
> devel_nack - We don't support downgrading.

Downgrading was actually Milan's idea during Evolution Test Day.

I still see following issue: What if user use NFS shared /home with 7.0 and 7.1 workstations (see Multiple Login feature).

Milan, could you describe your proposed fix here or in upstream bugzilla?

Right, we do not support downgrading, but what I was thinking about was to investigate whether the older addressbook cache would be able to work with the newer, instead of giving up due to a notice of an unknown column in one of its tables.

I had a chat with the author of this change, and it turned out we are out of luck, because:
a) there wasn't only added new columns to the tables, some values are stored
   in a fundamentally different way, unavailable to the old version
b) it's impossible to jump from newer version to the older and back,
   when accessing the same NFS home at one time, because contacts added/modified
   in one version would have missing summary information for the another
   version, which would cause incorrect results during searching

Well, the 'impossible' at b) is not accurate. There are some "options":
1) redirect evolution-related data into different XDG directories, thus they
   will not be shared at all, but will still be stored on the same NFS server
2) change summary versions each time the package is downgraded, but it's quite
   hard to do, because each backend can have implemented its own cache format,
   and the cache can be stored basically anywhere on the disk and, the most
   importantly, this doesn't cover on-the-fly version changes (like mounting
   the home from two versions of the system without involving rpm)
3) if the summary notices "too high" version, then it will downgrade it on
   its own, which means rebuilding it from scratch, with use of the vCard-s
   stored in the DB - it has also couple cons, like the rebuild would be
   done always after the switch, while a move from older to newer is done
   already within the migrate process, automatically. This migrate/downgrade
   can be time consuming, depending on actual cache size
4) have only one server with running evolution-data-server processes, and
   connect to it remotely, while supporting older (D-Bus) APIs by the clients,
   but I do not think it's practical to do too.

The most feasible way from my point of view is to use 1), not only because it doesn't require any changes on the evolution-related code, but because I expect that many other applications may suffer of the same downgrade issue. And also incorporate the 3), which will work fine for address books, if not switching between versions too often, for a price of slower open the first time the migration/downgrade is done. Of course, first do this upstream.

Matthew, what do you think?

If there is a need to run two different evolution instances on the same /home, then the XDS spec is the way to go, thus effectively do not share actual data, which means both evolutions should be configured separately. This problem is deeper than just with evolution.