+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.<div><br></div><div>I think we could also generate some kind of report with API changes, see <a href="http://stackoverflow.com/questions/6596364/tracking-c-lib-public-api-changes">http://stackoverflow.com/questions/6596364/tracking-c-lib-public-api-changes</a></div>
<div><br></div><div>- Nathan</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><div class="gmail_quote">On Wed, Aug 10, 2011 at 8:32 PM, Tim Sutton <span dir="ltr"><<a href="mailto:lists@linfiniti.com">lists@linfiniti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi<br>
<div><div></div><div class="h5"><br>
On Wed, Aug 10, 2011 at 11:58 AM, Martin Dobias <<a href="mailto:wonder.sk@gmail.com">wonder.sk@gmail.com</a>> wrote:<br>
> Hi there<br>
><br>
> watching the recent developments in the master branch I see various<br>
> nice improvements. And they have something in common: they do _not_<br>
> break API compatibility :-)<br>
><br>
> I would like to bring up this topic, because we should purge a lot of<br>
> cruft and deprecated APIs on the road to 2.0. The reason why I start<br>
> this is that I have been closely looking at the merge of threading<br>
> branch to master. The changes in that branch are essentially of three<br>
> types:<br>
> 1. asynchronous map rendering (i.e. ability to browse the map while it<br>
> is still being rendered)<br>
> 2. thread-safe API for vector access<br>
> 3. various speed optimizations<br>
><br>
> Asynchronous map rendering is relatively simple to merge and requires<br>
> only few API changes. But without new API for access to layers it is<br>
> possible to produce crashes (e.g. map is still being rendered when you<br>
> decide to start editing or do some analysis). The new API for vector<br>
> access (using iterators) will require removal of the old API<br>
> (select(), nextFeature()) in order to work well. And that means that<br>
> virtually any functionality that uses layers' data has to be updated<br>
> to new API. We need to break things in order to make threaded<br>
> rendering work.<br>
><br>
> The question is how to proceed and how to communicate that to users.<br>
> The procedure could look like this:<br>
> - set a date when we will start breaking API compatibility<br>
> - create a tag in git that would be the last revision of master branch<br>
> compatible with 1.x API<br>
> - change plugin manager so that it allows only plugins that say qgis<br>
> 2.0 is the minimal version for them to run<br>
> - change plugin installer so that it works only with new plugin<br>
> repository and shows plugins for qgis 2.0<br>
><br>
> Is there anything else we should consider? The point is to make the<br>
> transition as smooth as possible for those using qgis-master.<br>
><br>
> And what are your opinions when should we start with the breakage...<br>
> in a month? in a week? tomorrow? now? :-)<br>
><br>
<br>
</div></div>I think the fact that we are going to break API in 2.0 is well known<br>
and discussed often in releases, blogs, qgis hackfests etc. and is a<br>
general expectation when performing a major version numbering change.<br>
I think your approach is good (tag last api compatibility etc). As far<br>
as I am concerned we can go ahead with API breakage today. There are a<br>
number of other gut wrenching changes I would like to make for 2.0:<br>
<br>
- change theme to 'gis' theme by default<br>
- get rid of kids theme<br>
- rename default theme to 'legacy'<br>
- remove all deprecated api calls<br>
<br>
Many parts of our api have developed inconsistencies and I would like<br>
to spend some time putting my 'rpl' binary to good use trying to clean<br>
these up before we release. I think we should continue the practice of<br>
marking new api additions / changes with a @note added in 2.0 or<br>
@note replaces getLayerId in 2.0 etc. as far as possible so that<br>
people can adapt to our changes easily.<br>
<br>
Anyway +1 for API breakage from me - we will continue maintaining<br>
1.7.x for now anyway for those looking for stability. The number of<br>
things we can reasonable backport will shrink as we mess with the API<br>
but I don't see the impact to be too big.<br>
<br>
Regards<br>
<br>
Tim<br>
<div class="im"><br>
<br>
> Martin<br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
<br>
<br>
<br>
</div>--<br>
Tim Sutton - QGIS Project Steering Committee Member (Release Manager)<br>
==============================================<br>
Please do not email me off-list with technical<br>
support questions. Using the lists will gain<br>
more exposure for your issues and the knowledge<br>
surrounding your issue will be shared with all.<br>
<br>
Visit <a href="http://linfiniti.com" target="_blank">http://linfiniti.com</a> to find out about:<br>
* QGIS programming and support services<br>
* Mapserver and PostGIS based hosting plans<br>
* FOSS Consulting Services<br>
Skype: timlinux<br>
Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
==============================================<br>
<div><div></div><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div>