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

On 11/24/2016 11:48 PM, Zolnai Tamás wrote:
> 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.

There is no hard and fast rules which incompatible changes are OK and 
what are not---and that is rather by design.  Every case is different, 
and every case needs weighing of pros and cons.  So if you run into a 
situation where you think you might need an incompatible change, raise 
your voice early: on this mailing list, on IRC, in the ESC, or by adding 
reviewers to your Gerrit change.

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

What makes speculation about the consequences of changes in the UNO API 
so difficult is that UNO involves more than a single language.  All the 
language bindings (C++, Java, Python, .Net, ...) plus the binary UNO 
"hub" that interconnects those bindings need to be taken into account.