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

Hi Stephan,

2016-11-21 13:23 GMT+01:00 Stephan Bergmann <sbergman@redhat.com>:
> On 11/21/2016 12:53 PM, Zolnai Tamás wrote:
> > 2016-11-21 10:52 GMT+01:00 Stephan Bergmann <sbergman@redhat.com>:
> > > On 11/20/2016 12:43 AM, Tamás Zolnai wrote:
> > > > commit eb27a63a38ee7d15292dc40520b0605e4c2228e2
> > > > Author: Tamás Zolnai <zolnaitamas2000@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).

I know, what 3rd party code means, thanks. It was irony that Calc is
3rd-party code (well I don't know how to mark a sentence as irony in a
mail). It's problematic that Calc implemented on this way (using API).

But anyway I added a new functionality to Calc and for doing that I
needed to extend API too. I hope it's an acceptable reason. Can we
agree on that?

> 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.

OK. Then I'll move median to the end of this GeneralFunction enum, to
avoid broke those 3rd party code which uses enums on such way it leads
to problem.

Thanks,
Tamás