[Qgis-developer] OpenLayers plugin release and Python API breaks

[Matthias Kuhn]

Hi,

Communicating deprecation in a way, the developer will see it sounds 
like a good idea and I agree, that a concept to handle this (starting 
from 2.0) would make sense.

The question is, where and when to communicate it to the developer:
  * The MessageLog (why not)
  * stdout/stderr (sounds good as well, somebody will also see it when 
developing standalone applications)
  * The MessageBar (too obstrusive)
  * Only in debug mode or in release mode as well (A plugin developer 
does not have much reason to run QGIS in debug mode, so release would be 
nice as well)
  * Anything else?

I would propose to add a QGS_DEPRECATED macro which could be placed in 
any deprecated method which will take appropriate actions and 
deprecation methods will appear in a standardized way. (It should take 
an additional string argument, so one can specify the recommended way to 
fix this problem)
Maybe this can then be used to trigger something like the python recipe 
in Pirmins link [1]?

This would help in the case, when we see early, that the change is going 
to happen and when it's possible to leave both possibilities open for a 
while.

But I'm sure, there are still changes which cannot happen that way (i.e. 
The SIP update will convert QString to python unicode strings. Calling 
toString() on these will fail without deprecation. The threading branch 
will add functionality that needs the API to change without the 
possibility to keep deprecated methods). In these cases, a deprecated 
message could be thrown, once the updated is planned, but not when it's 
done.

Regards
Matthias

[1]: http://code.activestate.com/recipes/391367-deprecated/

On 01/24/2013 08:43 AM, Werner Macho wrote:
> Hi!
>
> I am not sure but I think what Pirmin meant here was that there was no 
> warning _message_.
> We all know that a lot of functions have been declared deprecated 
> since a very long time. But without knowing or getting a warning 
> message that THIS function is deprecated, I agree with Pirmin that 
> noone can see the deprecation until reading the source or .. until it 
> is cleaned out.
> Nevertheless it is good to clean the code (otherwise we would collect 
> deprecated functions forever)..
> So just as a reminder here to spit out warning messages for deprecated 
> functions next time ..
> Whenever this will be .. I hope not too soon ;)
>
> kind regards
> Werner
>
>
> On Thu, Jan 24, 2013 at 7:40 AM, Alexander Bruy 
> <alexander.bruy at gmail.com <mailto:alexander.bruy at gmail.com>> wrote:
>
>     Hi,
>
>     please note that most of this methods were marked as deprecated for
>     a long time. Some of them are deprecated since QGIS 1.6 or even
>     earlier.
>
>     On Thu, 24 Jan 2013 00:57:26 +0100
>     Pirmin Kalberer <pi_ml at sourcepole.com
>     <mailto:pi_ml at sourcepole.com>> wrote:
>
>     > Hi all,
>     >
>     > I found the time for an OpenLayers plugin release with merged
>     pull requests
>     > for Stamen map support and fixes for Python API breaks in master
>     branch (See
>     > https://twitter.com/PirminKalberer/status/294226472707715072 for
>     credits).
>     > The second point was quite annoying for many users and myself.
>     It is a really
>     > bad practice to break the API without deprecation messages when
>     calling these
>     > methods. There should be enough time (at least one minor
>     version) for
>     > developers for updating their plugins. In this case it would
>     have been easy to
>     > keep the old API and add a deprecation message similar to
>     > http://code.activestate.com/recipes/391367-deprecated/
>     >
>     > Regards
>     > Pirmin
>     >
>     > --
>     > Pirmin Kalberer
>     > Sourcepole  -  Linux & Open Source Solutions
>     > http://www.sourcepole.com
>     >
>     > _______________________________________________
>     > Qgis-developer mailing list
>     > Qgis-developer at lists.osgeo.org
>     <mailto:Qgis-developer at lists.osgeo.org>
>     > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>     --
>     Alexander Bruy
>     _______________________________________________
>     Qgis-developer mailing list
>     Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer