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

[Alexander Bruy]

In my opinion it is better to start now and have more time to update plugins
and test new changes.

So, +1 for breaking API now

2011/8/10 Marco Hugentobler <marco.hugentobler at sourcepole.ch>:
> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Alexander Bruy