Message de Jürgen Schmidt  date 2013-01-25 13:55 :
On 1/25/13 12:44 AM, Andrea Pescetti wrote:
Rob Weir wrote:
I also like the idea of marking a function as deprecated, maybe even
supporting the new and old together for a release, to give time for

If at all feasible, I would be for this. Ideally, we should be able to
install a legacy extension by: recognizing it's using legacy APIs or
conventions; displaying a warning; running it anyway, trying to be as
compatible as possible.

this would be indeed nice and if easy possible we would probably do
that. But the reality is that we don't have the resources to spent
enough time on this.

OK, we don't have enough resources, but then why spend scarce resources on secondary aspects of the API ? Even if it is simple to do, it's not a sufficient reason. Better develop or correct something that was requested by bug reports and that appears within available resources.

I am not against incompatible changes, if it is inevitable in order to provide a new feature very valuable for the API users. But the changes proposed by Ariel, as far as they are described, do not add anything useful for the API user.

We have as deprecated marked API's and I am sure that people will still
use it. These API's are probably deprecated since > 3-4 versions and we
should be save to remove them. But I am sure people would complain about
it if there macro, solution won't run anymore.

That's why I would prefer adding new services/interfaces, and keep the old ones with a mention : DEPRECATED, see so-and-so. A perfect example is service You can be sure that there are still many users of this now obsolete service. They are not aware of the new service, and don't care.

But you can also find many IDL pages flagged DEPRECATED without indication of an alternative, nor simply saying that the feature is killed. This is not helpful for the poor API user.


Reply via email to