<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 17, 2016 at 8:36 AM, Harald Sitter <span dir="ltr"><<a href="mailto:sitter@kde.org" target="_blank">sitter@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On Tue, May 17, 2016 at 11:06 AM, Jan Grulich <<a href="mailto:jgrulich@redhat.com">jgrulich@redhat.com</a>> wrote:<br>
> Hi,<br>
><br>
> we decided to drop WiMAX support in nm-qt when it's compiled against NM 1.2.0,<br>
> but this seems to break binary compatibility when nm-qt was previously build<br>
> against older NM version. I didn't realize this before that this could happen<br>
> and now I'm not sure how fix that.<br>
><br>
> We could either:<br>
> 1) Revert the change removing WiMAX support, but that would break ABI<br>
> compatibility one more time.<br>
><br>
> 2) Keep it as it is and let packagers know about this problem and ask them to<br>
> rebuild everything using nm-qt (plasma-nm, plasma-workspace) in case they<br>
> already have NM 1.2.0.<br>
><br>
> What do you think is a better option?<br>
<br>
</span>I am not sure how 1) would be an issue, or how it would break ABI<br>
again for that matter.<br>
If you add the relevant ABI back you are doing an ABI addition on top<br>
of the effectively new ABI, and adding things generally is a binary<br>
compatible change to both the original ABI (which would be back again)<br>
as well as the new semi-broken ABI as it would simply expand to again<br>
contain the removed ABIs. That said 1) is the better option. If one<br>
has built on top of nm-1.2, binary compatibility would be restored as<br>
the previous ABIs are back. If one hasn't built on top of nm-1.2,<br>
nothing would change and it would be as though the binary incompatible<br>
change never happened.<br>
<br></blockquote><div> </div><div>I agree with Harald here. manager.h is the only affected public header. You just need to re-add the five wimax related methods with an empty implementation and it should work. Fortunately, none of those methods are virtual, so adding them does not break ABI.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
2) would imply that we disregard the frameworks ABI stability promise<br>
which probably wouldn't be very nice. This option would also at the<br>
very least require a so-version bump to communicate the breakage<br>
properly.<br>
<span class=""><font color="#888888"><br>
HS<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">No ABI will be broken by re-adding those methods. Again, if any of those methods were virtual then re-adding them would indeed break ABI.</div><div class="gmail_extra"><br class=""><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><p style="margin:0px">Lamarque V. Souza</p><p style="margin:0px"><a href="http://planetkde.org/pt-br" target="_blank">http://planetkde.org/pt-br</a></p></div></div></div></div><br></div></div>