minutes of ESC call ...

[Zolnai Tamás]

Hi,

> * Pivot-Tables / UNO / API evolution (Eike)
>    + current state looks good (Eike)
>       + new feature will work.
>    + what needs clarification in future: when & how to break stable API
>       + if not absolutely necessary - don't do it.
>       + adding a new constant is more work & more ugly.
>    + new interface / Function2 bits is uglier for the API users (Stephan)
>       + will there be further extensions of that list of functions ?
>           + yes ? (Michael)
>           + perhaps not (Eike)
>       + if this is the only change this century - say go with incompatible change (Stephan)
>           + if will be further additions likely; perhaps pay the price now.
>    + dug at why addition to enums is incompatible (Kendy)
>       + fail to see why we should consider it incompatible.
>       + from semantic POV - fair cop.
>       + but everything we do is controlled by us
>           + code generated, JARs we generate from newer version.
>       + can generate some odd code here - that would cause issues.
>       + with normal use-cases; get a value of enum, do something, put it back.
>           + reasonably transparent.
>       + perhaps some scenario fails; if someone tries to cast random integers into
>          enums or no real technical reason not to extend an enum.
>           + problem with out-of-process Java code & older JAR file (Stephan)
>              + if you bundle JAR file with ext'n or app - have an issue (Kendy)
>       + mostly a moot discussion wrt. danger of extending it (Stephan)
>           + using constant-groups instead.
>       + Function - to a Constant Group ? (Thorsten)
>           + already done etc.
>       + Concern wrt. tone on each side (Thorsten, Michael)
>           + revert first and then discuss seems reasonable close to branch (Norbert)
>       + real problem is the UNO API used internally (Markus)
>           + long-term solution - to get rid of UNO API for internal code.
>           + happy to see this separated (Eike)
>       + could get the XPropertySet / Any to accept different types incoming (Michael)
>           + doesn't help so much for reading.
>       + What is the view wrt. changing byte-code we generate ? (Kendy)
>           + from 5.3 or 5.4 - so we can change the enums safely.
>           + codemaker magic - that needs some modification ?
>               + no-one looked into the .Net binding (Stephan)
>                   + don't see a way to change the Java code.
>                   + need an object representing that value
>                   + don't see the value.
>           + if we hit a place where an incompat way is preferred (Stephan)
>               + we just do that.
>           + enum situation in the past was a hard-wall (Kendy)
>               + larger API changes - asking consider changes here.
>               + in the future -> say - add a FUTURE_ITEMS (Michael)
>                   + then people get warned; we never emit this etc.
>               + not sure we get anything here, but if want to do it - why not ? (Stephan)
>       => anyone welcome to look into improving this.
>       + FWIW - Tamas' spare-time fun improvement (Michael)
>       + concern that we consider 3rd party apps carefully as we move ahead (Thorsten)

Thanks for discussing this, even tough this discussion did not lead to change.
I have only one question for the future, if it ever comes into my mind
to implement something which is related to this DAPI.
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.

Thanks,
Tamás