[Libreoffice-commits] core.git: 6 commits - offapi/com offapi/type_reference sc/inc sc/qa sc/source

[Stephan Bergmann]

On 11/21/2016 12:53 PM, Zolnai Tamás wrote:
> 2016-11-21 10:52 GMT+01:00 Stephan Bergmann <sbergman at redhat.com>:
>> On 11/20/2016 12:43 AM, Tamás Zolnai wrote:
>>>
>>> commit eb27a63a38ee7d15292dc40520b0605e4c2228e2
>>> Author: Tamás Zolnai <zolnaitamas2000 at gmail.com>
>>> Date:   Sat Nov 19 22:27:20 2016 +0100
>>>
>>>     [API Change] PivotMedian: Add median to pivot table function type
>>
>>
>> Are you sure that this incompatible change is acceptable?  Can you give some
>> rationale why that would be so (e.g., this functionality might be known to
>> be hardly useful for 3rd party code anyway).
>
> Yes. Calc code uses UNO API, that's why I needed to make this
> modification. The 3rd party code here is Calc.

No, 3rd party code is always code that's not shipped as part of LO (so 
we can't adapt it when doing changes like this, so need to rationalize 
whether doing a change like this is acceptable).

>> Why did you add the new member in the middle, changing the values of many
>> existing members?  Adding it to the end would at least reduce the risk of
>> breaking things.
>
> I thought we can change API on an incompatible way in main versions
> like 5.3. Was I wrong here?

We want to minimize impact on 3rd party code, so every such incompatible 
change needs to be done carefully, weighing the pros and cons.

> I added to the middle because I tried to add it to a reasonable place
> in this list. Median can be in a group with Average, Maximum and
> Minimum in meaning, but of course I can take it down to the end if
> that's your main problem.

My main concern is breaking the API.  A subordinate concern is breaking 
it in a more dangerous way than necessary.

> In general I don't agree with that idea to fear to change anything in
> the API, because it ties the development of it. API actually should
> follow the changes of the internal code. Of course, I accept that it
> should be done a reasonable way, along a reasonable policy. So my
> question is, when I can change API in an incompatible way? What is the
> policy here?

The general approach is to avoid incompatible changes as much as 
possible.  And if there is compelling reason and consensus to do such a 
change nevertheless, to do it in the least disruptive way.