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

[Martin Dobias]

Hi Tim!

On Mon, Mar 7, 2011 at 2:18 PM, Tim Sutton <lists at linfiniti.com> wrote:
>
> 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.

This is how it is already done in the branch.

But that's not enough for the compatibility. The iterator classes
always lock their source of data (layer/provider) in order to make
sure that only one thread accesses the data. So far so good. Now
imagine that we are running rendering of several vector layers (A,B,C)
in a separate thread. The rendering of A and B is in progress,
rendering of C is waiting. Now the user triggers an action in GUI that
starts iterating over layer C (using nextFeature() calls). If it
iterates just over few features, the layer C will stay locked
(expecting that more features will be fetched). Rendering of layer C
will therefore get stuck waiting for the lock - infinitely.

This is probably not the most common scenario, but having cases like
this might severly disturb the vector access in some cases.


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

I am not sure where to go from here. I think recently we had quite
decent releases with mostly stable features. This is a bit different
situation where we are one week before the feature freeze for 1.7
release - merging such amount of changes in core libraries seems quite
risky. I think if the threaded rendering appears in early 1.9.x
releases it should get quite a lot of testing anyway. Anyway, my
impression is that 90% of bug reports are from people who use the most
recent version (if not svn trunk).

Martin