[Qgis-developer] Project file backward compatibility

[Marco Hugentobler]

Hi Radim

 >Is it required that a development version (from master) understands
 >projects written by older version of the same major.minor? Probably
 >yes, because many people are using devel versions. The problem is,
 >that in that case, it would not be possible to use the version written
 >in a project to decide if it has already new format (the version is
 >for example 1.9.90-Alpha) and guessing the format from a string value
 >may be complicated.

Yes, it would be good to support reading of versions with the same 
major.minor. One possibility would be to define a new version number for 
every project file change (e.g. 1.9.0.1, 1.9.0.2, ...). That way it 
would be possible to invoke the proper project file transformation. For 
the sake of clarity, it would be good to synchronize it with the 
official version number, otherwise it might confuse people.

>Should we use a separate versions for project files? It would be also
>possible to add version attribute directly to XML tags if necessary,
>because in readXml() methods we don't have access to project file
>version.

In the case of the raster resampling changes, it should be 
straightforward to detect old versions from the xml itself. But yes, 
this kind of recognition could be difficult to do in other cases (and 
get messy if the xml format changes often).

 >This is another question, where should be isolated the conversion
 >code? I would prefer to keep it in one place, OTOH it may be often
 >related to providers so it should go to providers. BTW, there are
 >providers specific blocks of code in QgsRasterLayer and even in
 >QgsMapLayer read/writeXml methods.

Right. It may be cleaner if providers would have their individual 
readXML/writeXML methods. I'm not sure where the conversion code should 
go. For providers it might be good to have it in the provider lib (as 
providers can be added dynamically). For conversion code not located in 
plugin / provider libs (e.g. symbology code), it would be good to go to 
QgsProjectFileTransform to have everything in one place.

Regards,
Marco


On 16.04.2012 18:30, Radim Blazek wrote:
> On Mon, Apr 16, 2012 at 3:04 PM, Marco Hugentobler
> <marco.hugentobler at sourcepole.ch>  wrote:
>> Maybe I'll try to access the project file conversion methods from the qml loading methods.
> This is another question, where should be isolated the conversion
> code? I would prefer to keep it in one place, OTOH it may be often
> related to providers so it should go to providers. BTW, there are
> providers specific blocks of code in QgsRasterLayer and even in
> QgsMapLayer  read/writeXml methods.
>
>> Afaik there is no official policy yet (can be added to the coding standards
>> document if there are no objections).
> I have started http://hub.qgis.org/wiki/quantum-gis/Backward_Compatibility
>
> On Mon, Apr 16, 2012 at 3:08 PM, Paolo Cavallini<cavallini at faunalia.it>  wrote:
>>>> PF written by a lower major release must be supported? Example:  QGIS
>>>> 2.0 must support 1.7 PF?
>>> Is not required but would be nice.
>> I think every version should be able to open projects from at least the
>> previous one, otherwise users will have to recreate all their projects.
> I wrote to the doc, that it must support previous major version, but
> that is probably too much. OTOH, previous minor version is not enough
> IMO. What compromise would be the best and how to specify it, by a
> number of minor releases or by a maximum period between releases?
>
> Is it required that a development version (from master) understands
> projects written by older version of the same major.minor? Probably
> yes, because many people are using devel versions. The problem is,
> that in that case, it would not be possible to use the version written
> in a project to decide if it has already new format (the version is
> for example 1.9.90-Alpha) and guessing the format from a string value
> may be complicated.
>
> Should we use a separate versions for project files? It would be also
> possible to add version attribute directly to XML tags if necessary,
> because in readXml() methods we don't have access to project file
> version.
>
> Radim


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux&  Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee