>> 2) Implement a flexible properties framework in QGIS >> >> This is the kind of under-the-hood API changes and improvements I >> mentioned above. Stuff that brings our project forward, but under >> the hood - not visible for the user. This is the basis that later >> follow-up work can than build upon and benefit from. Stuff that later >> can also be funded by organizations/companies. Also time critical, to >> be done as soon as possible. Early in the 3.x life cycle when API >> changes are still possible. > > I also consider this one important, but it may be introduced later on.
Just to clarify (since I'm not sure if it was explicitly noted in the proposal) - this is more or less a happens-during-api-break or doesn't happen at all type change. To do it and maintain existing api would result in 1.5-2x the work required, and a horrible mixed api with many deprecated methods for the lifecycle of 3.x. Nyall _______________________________________________ Qgis-user mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
