Frank Schönheit - Sun Microsystems Germany wrote:
Juergen, Ariel,
to make it short, i would support you to add it. If we make the change
we should start with a new wiki page to document the change and a
migration path even if it would be trivial.
okay. What location do you suggest? Do we already have an entry point in
the wiki to the overall topic "incompatible API changes"?
ooh, we have
http://wiki.services.openoffice.org/wiki/API/Concepts_API_changes which
is currently empty and where i wanted summarize and document the outcome
of our discussions :-(
I would suggest
http://wiki.services.openoffice.org/wiki/API/Changes with a display title
{{DISPLAYTITLE:Incompatible API changes}}
...
* API changes in OpenOffice.org 3.2
<DPL>category=APIChanges_v3.2</DPL>
...
[[Category:API]]
[[Category:APIChanges]]
And for your specific change
http://wiki.services.openoffice.org/wiki/API/Changes/css_awt_XView
{{DISPLAYTITLE:Incompatible API change of com.suns.star.awt.XView}}
...
[[Category:API]]
[[Category:APIChanges]]
[[Category:APIChanges_v3.2]]
With a specific category for each version we can easy collect a list of
all API changes for a specific version and with the general APIChanges
category we can collect all API changes...
It's a quick idea to put the whole stuff in some organized structure.
What do you think?
was there an agreement on that? I didn't have time to understand the reasons
given for adding a FilterOperator2, carrying with it a TableFilterField2 and a
XSheetFilterDescriptor2; but the names just tell me there was no agreement.
I think that there was an agreement to allow incompatible changes for
major releases.
Yes.
And we talked about some specific changes that might be
also allowed for minor releases. But this changes are not yet defined in
detail...
And that's what I'm trying to find out - where's the line to be drawn
between "allowed for majors only" and "allowed for minors, too". We
already agreed that making optional properties on old-style services
non-optional is below that line, i.e. allowed for minors.
Adding a method to an existing interface as Frank suggested
would be of course such a change. No influence on Basic or other
languages using invocation. Only build incompatible in C++ as long as
you don't implement the interface on your own...
The "as long as" is the tricky part in such cases. For instance,
grokking for XView gave me implementations of this interface in the
presenter console, which is delivered as a C++ extension. So, in such a
case, I would have a hard time arguing that adding a method is no
problem at all. Luckily, this was css.frame.XView, not css.awt.XView :)
The given XView interface is effectively *only* implemented in the
toolkit module, and chances that it's implemented outside the OOo code
base are rather low (since all the code around it does not really allow
for pure UNO components outside the OOo code, but that's another topic).
So, I'd say we're on the safe side here.
i agree that we are probably safe here. But it shows also that a general
rule is or can be problematic. Whereas a change like yours is probably
harmless other changes of the same category can break many external
solutions depending on the usage of the changed interface. That is the
reason why we should discuss the changes in public and find a common
agreement for the proposed changes...
Juergen
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
