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 <[email protected]>: > 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 <[email protected]> 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 >> > [email protected] >> > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > -- > Dr. Marco Hugentobler > Sourcepole - Linux & Open Source Solutions > Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland > [email protected] http://www.sourcepole.ch > Technical Advisor QGIS Project Steering Committee > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Alexander Bruy _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
