[Kdenlive-devel] How to handle support for old file format versions reliably

Mads Bondo Dydensborg mads at dydensborg.dk
Sat Nov 22 15:48:06 UTC 2008

Hi there

In .kdenlive project files, the kdenlive_doc section is marked with a version. 
Is it correctly understood, that 

Kdenlive 0.5 used project file version (pfv) 0.6
Kdenlive 0.6 used project file version (pfv) 0.7
Kdenlive 0.7 uses project file version (pfv) 0.8

I think the support for pfv 0.6 is tolerable. There is absolutely no support 
for handling pfv 0.7 in a way that is different from 0.8 

IMHO, we need to make absolutely sure that we can support our old file formats 
from now on, that is, we do not break support for pfv 0.8 in any future 
version (ok, in 3-4 years, perhaps the situation is different, but you get my 

The current method of supporting old file versions is implemented in the 
KdenliveDoc class. Upon reading a file, it matches its version against 0.8 
(by comparing a double/float using == btw, which is always dangerous). If 
its != 0.8 it calls convertDocument. This matches against 0.7 and gives up, 
then against 0.6 and converts from 0.6 to 0.8 if doc is 0.6.

I think we should redesign the flow to always call convertDocument. In convert 
document, we should first test against the older version, then repeatedly 
convert them up. We should also handle too-new versions. So, convertDocument 
would right now be changed to do

0.6 => 0.8
0.7 => 0.8 (I'll try to write this)
0.8 => nothing
> 0.8 => error/warning:file format too new

In the future it would be something like this, given two additional pfv 
versions, 0.8.1 and 0.9:

0.6 => 0.8
0.7 => 0.8 (I'll try to write this)
0.8 => 0.8.1
0.8.1 => 0.9
0.9 => nothing
> 0.9 => error/warning: file format too new

This would mean, that for any changes to the way the project file is layed 
out/constructed, we step the pfv number, and then only have to write a 
conversion routine for exactly the just implemented change. Of course, this 
requires that changes can always be made from an older to a newer format, but 
I am pretty sure, that that is the case.

The convertDocument should probably also indicate to the caller if the version 
actually changed, and allow the GUI to ask something like: "You have loaded a 
project saved in an older version of Kdenlives file format. The project has 
been succesfully converted to the new format. Would you like to write your 
project to a new file, or overwrite the old one". I am not sure this is 
strictly needed though, but perhaps it will save the day when we at some 
point introduces a bug in the conversion routines, or when somebody loads and 
edits a project in a new version of kdenlive, then discovers that it can no 
longer be loaded in an older version of kdenlive. 

See also this issue: http://www.kdenlive.org/mantis/view.php?id=229

Your comments are much appreciated. I don't mind reorganizing the 
convertDocument function and KdenliveDoc class, if you think this is the 
right approach.



P.S. And of course I will create an issue for this - just need some comments 
first :-)

Mads Bondo Dydensborg   mads at dydensborg.dk   http://www.madsdydensborg.dk/

They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
               - Ben Franklin, Historical Review of Pennsylvania, 1759

More information about the Kdenlive mailing list