I'm not sure I like the idea of adding the data there twice. It feels like pollution that we inevitably need to deal with at some point!
I'd really rather defer the fix for ~3 months until QGIS 4.0, especially since the bug it fixes has come unnoticed for sooo long :) Best Stefanos On Thu, 12 Jun 2025 at 15:50, Denis Rouzaud <denis.rouz...@gmail.com> wrote: > just thinking that it will probably give the same error message! > so maybe a v2 like: > > <properties> > <foo> > <bar type="QString">baz</bar> > </foo> > </properties> > <properties-v2> > <properties name="foo"> > <properties name="bar" type="QString">baz</properties> > </properties> > </properties-v2> > > Le jeu. 12 juin 2025 à 14:28, Denis Rouzaud <denis.rouz...@gmail.com> a > écrit : > >> Hi, >> >> I did something similar in the symbology area and I went for saving twice >> the data. >> We could probably leave the two at the same time in the same tag: >> >> <properties> >> <foo> >> <bar type="QString">baz</bar> >> </foo> >> <properties name="foo"> >> <properties name="bar" type="QString">baz</properties> >> </properties> >> </properties> >> >> Old QGIS would only save the old, new QGIS would save both and use the >> new if it exists. >> >> Best of the 2 worlds? >> >> Cheers, >> Denis >> >> >> >> Le jeu. 12 juin 2025 à 13:55, Stefanos Natsis via QGIS-Developer < >> qgis-developer@lists.osgeo.org> a écrit : >> >>> Hi list >>> >>> During the last dev cycle, a change was introduced in the way that >>> properties are stored in the .qgs xml file >>> https://github.com/qgis/QGIS/pull/60855 >>> >>> While this solved a real issue (data-driven properties could result in >>> an invalid property name with a leading digit) in an elegant way and is >>> technically backwards compatible (projects generated with older versions >>> can be opened without issues), it has the side effect that projects stored >>> with 3.44 will not properly load in older QGIS versions (stored properties >>> are ignored and also project CRS is undefined). Plugins could also >>> malfunction as they often use project properties for storing their >>> project-related configurations. >>> >>> One potential solution would be to backport this to LTR, however from my >>> experience a good percentage of the users use older QGIS versions and even >>> those on LTR do not always upgrade as soon as a new release is out, so >>> backporting could eventually make things worse! >>> >>> With QGIS 4.0 around the corner, imho, it would be better to defer this >>> change for a couple more months and only include this kind-of-breaking >>> change in QGIS 4.0 >>> >>> I briefly chatted with Jurgen at the hackfest about this and while >>> acknowledging the issue, was not super happy to revert, so I'm interested >>> in gathering more opinions here. >>> >>> Best >>> Stefanos >>> >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer@lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
