[Qgis-developer] 2.0 Stable API?

[Matthias Kuhn]

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer