Re: [Libreoffice-qa] minutes of ESC call ...

2016-11-24 21:30 GMT+01:00 Thorsten Behrens <thb@libreoffice.org>:
> Michael Meeks wrote:
> > On 24/11/16 18:34, Zolnai Tamás wrote:
> > > Can I have some code pointers from the last 5 years which shows when
> > > it is "absolutely necessary" to break compatibility? To see when it's
> > > acceptable to do such thing.
> >
> >       I think its worth discussing it with the ESC if its significant.
> Seconded. And if you look at the type reference history, you notice we
> were trying really quite hard not to break published API. It can be
> avoided almost all the time.
>
> I'll repeat the point I made during the ESC here: there's a price when
> one breaks things (API, work flows, interop) for users - beyond a
> certain limit, they consider your project not worth using
> anymore. Since the livelihood for a number of people on this list
> depends on LibreOffice having more users, instead of having less, I
> really rather feel quite strongly about those things.

Hi Thorsten,

I agree with you about that there's a price of breaking things, but I
also see that LibreOffice struggles with regressions and solving
something in ~500 lines of code change instead of ~15 lines means some
new potential regressions.
However it's true that regressions in our core code can be fixed by
ourselves, but regressions coming from API incompatibility can be
fixed only by 3rd party code maintainers (by updating their code or
updating jar files). On the other hand regression in core code affects
all LO users, while API incompatibility affects only those who uses
the specific part of the API.
But, it's OK if this API is working like that (or at least I can't do
anything with that). It just a bit surprising for me. I used other
APIs/SDKs as a user and there it was not a problem if an enum was
extended. I never expected as an SDK user that a published enum will
never change, but those APIs were written in C/C++, so maybe it's
something about Java code.

Best Regards,
Tamás