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
<[email protected]> 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<[email protected]> 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
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
