On Tue, May 17, 2016 at 8:36 AM, Harald Sitter <sit...@kde.org> wrote:
> On Tue, May 17, 2016 at 11:06 AM, Jan Grulich <jgrul...@redhat.com> wrote: > > Hi, > > > > we decided to drop WiMAX support in nm-qt when it's compiled against NM > 1.2.0, > > but this seems to break binary compatibility when nm-qt was previously > build > > against older NM version. I didn't realize this before that this could > happen > > and now I'm not sure how fix that. > > > > We could either: > > 1) Revert the change removing WiMAX support, but that would break ABI > > compatibility one more time. > > > > 2) Keep it as it is and let packagers know about this problem and ask > them to > > rebuild everything using nm-qt (plasma-nm, plasma-workspace) in case they > > already have NM 1.2.0. > > > > What do you think is a better option? > > I am not sure how 1) would be an issue, or how it would break ABI > again for that matter. > If you add the relevant ABI back you are doing an ABI addition on top > of the effectively new ABI, and adding things generally is a binary > compatible change to both the original ABI (which would be back again) > as well as the new semi-broken ABI as it would simply expand to again > contain the removed ABIs. That said 1) is the better option. If one > has built on top of nm-1.2, binary compatibility would be restored as > the previous ABIs are back. If one hasn't built on top of nm-1.2, > nothing would change and it would be as though the binary incompatible > change never happened. > > 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. > 2) would imply that we disregard the frameworks ABI stability promise > which probably wouldn't be very nice. This option would also at the > very least require a so-version bump to communicate the breakage > properly. > > HS > 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. Lamarque V. Souza http://planetkde.org/pt-br
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
