On 1/25/13 3:50 PM, Bernard Marcelly wrote: > 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.
because you can't tell volunteers what they should do. If somebody like to work on bugfixes, fine, perfect but if somebody prefers to improve other areas it also fine. I am happy for anybody who is interested to work on the code in general ;-) > > 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. I agree and the problem with this example is that it was not clear communicated. We should include such changes clearly in the release notes and should provide links to the migration path. > > 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. indeed and sometimes the intention is simply to drop this API's because the mistake was to provide an API for it from the beginning and it makes more problems than it helps. Or name it the missing feature of private API's. But where I am thinking about it, it could be so easy by simply putting private API's in a private namespace/module. This can be easy filtered when generating API reference docu etc. Juergen
