[Qgis-developer] Breaking API and merge of threading branch

[Marco Hugentobler]

Hi Martin,  Tim

I'm also in favour of breaking the API right now (it was only per coincidence 
no one did it so far).
At the last developer meeting, someone proposed to have a list wotj the API 
breakages on the wiki as help for plugin authors.

Regards,
Marco

Am Mittwoch, 10. August 2011, 12.32:32 schrieb Tim Sutton:
> Hi
> 
> On Wed, Aug 10, 2011 at 11:58 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
> > Hi there
> > 
> > watching the recent developments in the master branch I see various
> > nice improvements. And they have something in common: they do _not_
> > break API compatibility :-)
> > 
> > I would like to bring up this topic, because we should purge a lot of
> > cruft and deprecated APIs on the road to 2.0. The reason why I start
> > this is that I have been closely looking at the merge of threading
> > branch to master. The changes in that branch are essentially of three
> > types:
> > 1. asynchronous map rendering (i.e. ability to browse the map while it
> > is still being rendered)
> > 2. thread-safe API for vector access
> > 3. various speed optimizations
> > 
> > Asynchronous map rendering is relatively simple to merge and requires
> > only few API changes. But without new API for access to layers it is
> > possible to produce crashes (e.g. map is still being rendered when you
> > decide to start editing or do some analysis). The new API for vector
> > access (using iterators) will require removal of the old API
> > (select(), nextFeature()) in order to work well. And that means that
> > virtually any functionality that uses layers' data has to be updated
> > to new API. We need to break things in order to make threaded
> > rendering work.
> > 
> > The question is how to proceed and how to communicate that to users.
> > The procedure could look like this:
> > - set a date when we will start breaking API compatibility
> > - create a tag in git that would be the last revision of master branch
> > compatible with 1.x API
> > - change plugin manager so that it allows only plugins that say qgis
> > 2.0 is the minimal version for them to run
> > - change plugin installer so that it works only with new plugin
> > repository and shows plugins for qgis 2.0
> > 
> > Is there anything else we should consider? The point is to make the
> > transition as smooth as possible for those using qgis-master.
> > 
> > And what are your opinions when should we start with the breakage...
> > in a month? in a week? tomorrow? now? :-)
> 
> I think the fact that we are going to break API in 2.0 is well known
> and discussed often in releases, blogs, qgis hackfests etc. and is a
> general expectation when performing a major version numbering change.
> I think your approach is good (tag last api compatibility etc). As far
> as I am concerned we can go ahead with API breakage today. There are a
> number of other gut wrenching changes I would like to make for 2.0:
> 
> - change theme to 'gis' theme by default
> - get rid of kids theme
> - rename default theme to 'legacy'
> - remove all deprecated api calls
> 
> Many parts of our api have developed inconsistencies and I would like
> to spend some time putting my 'rpl' binary to good use trying to clean
> these up before we release. I think we should continue the practice of
> marking new api additions / changes with a @note added in 2.0  or
> @note replaces getLayerId in 2.0 etc. as far as possible so that
> people can adapt to our changes easily.
> 
> Anyway +1 for API breakage from me - we will continue maintaining
> 1.7.x for now anyway for those looking for stability. The number of
> things we can reasonable backport will shrink as we mess with the API
> but I don't see the impact to be too big.
> 
> Regards
> 
> Tim
> 
> > 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