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

[Marco Hugentobler]

Hi 

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

We already have a number of new features for 1.7 (hopefully including the 
raster provider branch). So for me it would be ok to have 1.7 as the last API 
compatible release and doing the threading branch merge just after the 
branching for 1.7.

Anyway, it would be good to merge the changes from trunk into the threading 
branch already now. Like this, people who need e.g. the globe plugin could 
work with the threading branch sources until 1.7 is branched. Additionally, it 
is easier to test the threading branch in productive work with all the fixes 
and new features from trunk.

Regards,
Marco




Am Montag, 7. März 2011, um 14.18:15 schrieb 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


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee