[Qgis-developer] Branch status for merge and release timeline proposal

[Tim Sutton]

Hi Martin

On Mon, Mar 7, 2011 at 12:34 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> On Mon, Mar 7, 2011 at 11:20 AM, Ivan Mincik <ivan.mincik at gmail.com> wrote:
>> Martin, have You found some good solution for threading problems in
>> Python (threading branch) ?
>
> Yes, I have fixed that few weeks ago.
>
> But the problems I am facing now are related to compatibility - I was
> unable to reach 100% compatibility with vector layer API until now.
> The functions select() and nextFeature() in both QgsVectorLayer and
> QgsVectorDataProvider may cause various problems with threading. I
> have implemented a new approach with QgsFeatureIterator class which
> encapsulates these methods and they should be safe. We need to support
> those original API methods, but they may cause havoc when they are run
> while rendering in threads. QGIS application can be simple modified to
> use just the new (safe) API using QgsFeatureIterator, but what about
> all the plugins??
>
> Therefore I wonder if the merge shouldn't be postponed until we start
> transition to 2.0, otherwise we may end up with either deadlocks or
> data corruptions. (Yes, threads are evil.)
>
> Other possibility would be to merge just stuff that is safe to merge
> (various optimizations and refactorings) and keep back the threading
> until we can break backward compatibility.
>
> Comments?
>

Is it not possible to reimplement the old methods as thin wrappers
around the new QgsFeatureIterator class and at the same time mark them
in doxygen as deprecated? Sorry I havent looked in the code itself so
it may be a dumb question.

With regards to API backwards comptability, we have been pretty good
at maintaining it to now, though its a thing we strive for and not
absolutely guarantee and if our docs / wiki etc say otherwise we
should adjust them. The one time we broke it in the 1.x series was
because we had no other choice IIRC. For me getting your work into
trunk now is important as it will give us a window of around 6 months
for it to be 'gorilla tested' by 100k+ users out there before we
release it in 2.0.

An alternative option is that we just freeze our 'stable' releases at
1.6 (or maybe a last 1.7 release with no threading) and jump right on
to doing 1.9.x releases in the run up to September. However I would
rather put the things we are developing into mainstream releases since
(I know some people hate this idea) our users are also our testers.

Regards

Tim

> Regards
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
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
==============================================