openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernard Marcelly <>
Subject Re: Incompatible change for extensions
Date Fri, 25 Jan 2013 14:50:45 GMT
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
>>> transition.
>> 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.


View raw message