chatmail
Don't allow importing incompatible backups [Forewards compatibility]
Problem
its possible to import backups from new versions into old versions, but they might be incompatible, especially when we decide to remove old columns in the future.
Proposed solution
store a minimum_db_version value inside of the backup and fail to import if that value is higher than the current db_version of the core. Provide an clear error message like: "Can't import backup created with a newer deltachat version. Please update your Deltachat app before importing this backup"
Why now?
This is a change that needs to be present in many older versions before it becomes useful. Even if @r10s might say that we don't need it right now, it is definitively good to have the possibility in the future.
Besides it is not a hard thing to implement, because it's only in the core and the error message would appear as backup import failed error message, which could be displayed using data2 of DC_EVENT_IMEX_PROGRESS for the error message, like configure is doing it.
related: https://github.com/deltachat/interface/issues/27
This could also be extended to opening an account created with a newer incompatible core. This could happen on desktop when the user has multiple AppImages from different versions and chooses to open an old one by accident.
I suggest that we simply don't allow importing the backup if it has the database version (dbversion row in the config table) higher than currently known. This will require no maintenance and thinking about whether update is compatible or not. Note that many deltachat core releases do not introduce SQL migrations at all, the best way to avoid compatibility problems is to avoid changing the database schema.
I suggest that we simply don't allow importing the backup if it has the database version (dbversion row in the config table) higher than currently known.
hm, if we go for that, as we do not release all systems the same time, there will always be some days or weeks after releases where ppl have no chance to transfer backups between systems or set up a second device.
same would be the case if we have a dedicated number that changes only on "incompatible versions".
both would worsen UX.
i also fear that, once we have a "incompatible version" number, we will make use of it, and do $things we would avoid currently. of course, this is theoretical, but trying to predict the future is :)
the best way to avoid compatibility problems is to avoid changing the database schema
this.
and i think, we did a quite good job at that the last years, doing no or only careful adaptions of the scheme. among all problems, we had virtually no real issue with migrations.
