[Qgis-developer] Merging of incompatible changes

[Martin Dobias]

Hi Pirmin

On Wed, Oct 24, 2012 at 10:39 PM, Pirmin Kalberer <pi_ml at sourcepole.com> wrote:
>
> 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.

I would be more conservative with such estimates, maybe 500 plugins
altogether? But that's not really important for the discussion.


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

I understand your concerns - but I can imagine that if the API changes
are postponed to QGIS 3.0, in three years there will be five times
more plugins and therefore several times more code that would need
updating. So will we again shift the changes to QGIS 4.0 in order to
not break them?

My point is that there will be always push from users not to break
anything - and we need to decide at some point to do the necessary
cleanup and do not postpone it forever.

What about other changes, like removal of old symbology and old
labeling? Those will also break many plugins...

Regards
Martin