[Qgis-developer] Merging of incompatible changes

[Pirmin Kalberer]

Hi Martin, Andreas and others,

Am Mittwoch, 24. Oktober 2012, 16.13:34 schrieb Andreas Neumann:
> 
>  Tim should correct me - but as far as I remember we said that threading
>  support is one of the major things we want to see in QGIS 2.0 (along
>  with raster redesign, atlas printing and others). But none of us were
>  sure in what timeframe Martin can work on it and when it will be
>  finished. Therefore we decided not to make it a blocker.
> 
>  We also decided that the geometry refactoring (for arcs, splines,
>  z-values, m-values, multitype geometries, etc.) should be done after
>  QGIS 2.0. I am not sure if this would again mean API breaks ...
> 
>  So I am against postponing the multithreading work and I had the
>  impression that this was the conclusion of others as well.

I'm waiting for Tim dropping into the discussion as well... In Essen, we 
decided against integrating major new features (like multithreading) into the 
next release. We did decide filling the missing gaps to fully replace old 
symbology and old labelling (Paolo: Kickstarter pledge on the way?) and 
polishing the many new features already integrated.

We already have some API breaks. I've spent quite some time in Essen to get a 
full list of it:
http://hub.qgis.org/wiki/quantum-gis/API_changes_for_version_20#Full-diff
My estimation is, that about 1% of all existing plugins are affected by the 
API changes in the current master branch. So we're talking of about 2 of 160 
plugins in the central repo and maybe 160 of 16'000 unpublished user plugins 
(any better estimation than 1:100 between published and unpublished plugins?).
Martins proposed API change means we break 160 of 160 and 16'000 of 16'000 
plugins. It will take years to bring them all in sync with QGIS again.

And we're not only talking about plugins. We're talking about a possible 2.0 
release with WMTS, WFS-T, huge raster improvements including performance 
factor 4 with PNG/8, Atlas printing, Sextante and minor things like fixed 
Shapefile support in Q1/2013. The other option is a new QGIS with release date 
far in 2014 and a giant gap between users working with QGIS 1.7.4, 1.8++ and 
developers working on a new QGIS and releasing plugins in a separate 
repository. Companies like ours will get paid for maintaining branches for 
customers who need stable and compatible releases. There will be 1.8 custom 
branches with backported fixes/features and a garanteed non-frozen 1.9 branch. 
I will remind Marco in 2014 of his +1 when he's still compiling QGIS 1.8 and 
investing a lot of time backporting fixes to a single-threaded version. I 
would very much prefer let him work on *new* features, which are a profit for 
*all* users, like in recent years.

We are on a developer list here. As a developer I like the proposed changes 
very much. QGIS is made by developers, but is also made for users. And 
sometimes we should care about users - even the 99% Windows users. That's why 
I'm voting for a polished 2.0 release in a few month with the great feature 
set we already have.

Regards
Pirmin

--
Pirmin Kalberer
Sourcepole  -  Linux & Open Source Solutions
http://www.sourcepole.com