Hi, I would like to try wherever possible to only extend the API and not change or remove existing methods. This will help to ensure, that plugins written for 2.0 will stay working for minor releases.
If there is a (more clever/better) replacement for a method, the old one should be deprecated. There are several ways to do this e.g. Q_DECL_DEPRECATED in C++ /Deprecated/ for SIP annotations but I'm not sure what exactly they do. More important IMO is to write a note about what should be used instead in order for your code to be prepared for the future, like "@deprecated: This method will be removed in QGIS 3. Use abc( xyz ) instead." Often a simple default value for a newly introduced parameter is enough anyway. There may be places, where it is not possible to keep the API or the amount of extra work required to keep it would be enormous. In this cases, I think we could think of changes to the API, but they need careful consideration. In short: I would like to keep plugins working without changes wherever possible. Matthias On Mit 30 Okt 2013 04:59:38 CET, Nathan Woodrow wrote: > Hey all, > > Now that we have 2.0 out does that mean we are maintaining a stable > API? I have a fix for a bug in the composer export which requires an > API to public facing APIs, changing int to QString. > > What is the procedure now. Do we add overloads for something like > this and depreciate the old method? > > Regards, > Nathan > > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
