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
com.sun.star.document.DocumentInfo. 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.
Bernard
