Hi All
Firstly my apologies for taking so long to join in to this thread (and for top posting) - I haven't been able to come up for air since leaving Essen. In terms of the release roadmap for 2.0 the following items were discussed in the hackfest in Essen as being the key features we would hold the release for: 1) Raster overhaul 2) WMTS Support 3) Atlas integration for composer 4) WCS Client support 5) Transactional WFS support for QGIS Server 6) SIP Bindings revision 7) Symbology overhaul (needs support for random colour assignment and property change on multiselections) 8) Sextante 9) Threading (non blocker wait fro 3.0) 10) Labelling overhaul 11) Diagrams overhaul (and remove of old implementation) 12) Oracle support (non blocker for 2.0) 13) Web site and docs update 14) Universal usage of expression builder We agreed that when these features are present we will roll out the release, with the hope that that could take place early next year. Come end of December I think we should take a look at the items listed and if any are obviously not making headway we should remove them from the blocker list or find out if there is a way to bring them to the foreground. The list above was also not intended to be exclusive, so if other developments are offered for incorporation they will be considered and accepted / declined on their merits. <release manager hat off> * My opinion on whether or not to include Martin's work is that we should include it as I prefer one large disruption (along with raster and other API breaking changes) rather than that we have a succession of them. As Martin pointed out we have maintained 1.0 compatibility for around 4 years and it would be nice to have a stable API again for the next few years. * I also think we need to be pragmatic here - we have a window of opportunity with Martins work that may not come around in the near future again - if he gets busy with his job etc. we may land up back in the situation we had with the last threading branch. * Adding a max version identifier as has been suggested (with max 1.8 being assumed if min version <= 1.8 and max version not explicitly given) seems like a pragmatic way to deal with marking plugins as unsupported. * One of the major limitations I and the many people that contact me about QGIS experience is lack of performance. Just yesterday I got an email from someone in Sudan trying to use QGIS to work with ~300 000 point records and it taking 4 hours to do some simple operations on the dataset. I know you can deal with large datasets more effectively in e.g. PostGIS but this is beyond the skill level of many of the users who naturally gravitate towards QGIS 'because it is easy' - I think we tantalise people with an increasingly rich feature set and then frustrate them with slow performance. Putting in threading (and other performance boosting improvements) will help to improve this. For these reasons I vote +1 for Martin to merge in his work. <release manager hat off/> A few other general thread responses (with my release manager hat back on again): - no bugfix releases for 1.8 are planned unless someone wants to volunteer for the maintenance, release and packaging process we simply don't have the manpower - no 1.9 release - we have broken API already and following http://semver.org/ this precludes us doing another release. - release cadence - releasing yearly is probably unlikely developers (and developer funders too) need to see their work rolled out into public releases regularly. If you want a yearly cadence, simply pick one release a year and hold off on deploying newer releases in that year. - managing expectations - I think it is very important that we (the docs and community team especially) really prepare good materials to accompany the release explaining the implications of the release and the path to follow to get their preferred tools working on 2.0 - as Code PSC representative, Marco H ultimately should be the one who facilitates the decision as to whether Martins work can be merged, >From a release point of view I would support its inclusion assuming Marco is happy that it is stable and doesn't break QGIS in new and mysterious ways. A last 'dreaming of a nicer vector api' note for Martin: Since you are adjusting the feature iterator API, wouldn't it also be nice to support this: for reading: while myProvider.nextFeature(myFeature): # or equivalent in new api myGeometry = myFeature.geometry() myFooValue = myFeature['foo'] .... do stuff ..... And for writing: myNewFeature = QgsFeature() myGeometry = QgsGeometry.fromWkt(myRectangle.asWktPolygon()) myNewFeature.setGeometry(myGeometry) myNewFeature['foo'] = 'bar' myResult = myMemoryProvider.addFeatures(myFeatures) myMemoryLayer.commitChanges() In otherwords, the AttributeMap is nice for feature introspection but its heavy baggage when all you want to do is write or read features. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) ============================================== Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net ============================================== _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
