+1 for starting now. Better to start early so we and plugin devs can start moving over, esp regarding the multi threading API, then leave it till the end.
I think we could also generate some kind of report with API changes, see http://stackoverflow.com/questions/6596364/tracking-c-lib-public-api-changes - Nathan On Wed, Aug 10, 2011 at 8:32 PM, Tim Sutton <[email protected]> wrote: > 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 > > > > > > -- > Tim Sutton - QGIS Project Steering Committee Member (Release Manager) > ============================================== > Please do not email me off-list with technical > support questions. Using the lists will gain > more exposure for your issues and the knowledge > surrounding your issue will be shared with all. > > Visit http://linfiniti.com to find out about: > * QGIS programming and support services > * Mapserver and PostGIS based hosting plans > * FOSS Consulting Services > Skype: timlinux > Irc: timlinux on #qgis at freenode.net > ============================================== > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
