Le Tuesday 08 March 2011, Raphael Kubo da Costa a écrit :
> Lamarque Vieira Souza <lamar...@gmail.com> writes:
> > I am no expert in binary compatibility but as far as I know adding a new
> >
> > method should not affect binary compatibility.
>
> Adding a new method is OK. In this case, though, you're changing the
> access rights to one method, making it public when it was previously
> private. It is listed as a "DON'T" in [1] ("You cannot... -> For
> existing functions of any type -> change its signature").
>
> [1]
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
Moving to private to public is a problem only
- On windows. Is binary compatibility maintained there?
- If the function is called from a plugin. And since it is private, it is
unlikely. (Unless it appears in some inlined code)
So I think it is quite safe in this case.
>
> > Anyway, binary compatibility in libkopete is a waste of time in my
> > oppinion. No other program besides Kopete use that library
There could be third party plugins that uses libkopete.
That said, I also think maintaining binary compatibility is a waste of time.
(Is there many 3rd party plugins? Can't they afford to be compiled for each
version?)
> To begin with, it'd be good to know if we do guarantee binary
> compatibility at all.
>
> I'm CC'ing Matt Rogers as he probably has more information on this from
> the old times. mattr?
>
> > but there are a lot of people complaining about Kopete bugs in
> > bugs.kde.org and several patches that should be already in Kopete,
> > some of then are waiting more than a year to go in.
>
> Erm, I think this is unrelated to the discussion.
_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
