>> 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.
Qgis-user mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user