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

[Nathan Woodrow]

+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 <lists at linfiniti.com> wrote:

> 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
> >
>
>
>
> --
> 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
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20110810/f3ab8462/attachment.html