https://bugs.kde.org/show_bug.cgi?id=433090
--- Comment #9 from Harald Sitter <sit...@kde.org> --- (In reply to Antonio Rojas from comment #8) > (In reply to Harald Sitter from comment #7) > > That may well be but then the soversion will still have to change. > > > > The only options for any library are: > > > > a) when ABI is broken the soversion is bumped > > b) nobody checks if ABI is broken and the soversion is directly tied to the > > release version e.g. the there is no libfoo.so.5 but only a > > libfoo.so.5.20.12.2 > > c) the library has no version, is considered private, and doesn't advertise > > itself for external use (install with NAMELINK_SKIP + no cmake config) > > > > One may pick any of the three. > > (b) would be a nightmare for packagers, we'd need to rebuild everything > after every bug fix release (note that this affects every PIM library, not > just akonadi) > For (c) it is too late, there is stuff using pim libraries already. > The right way is (a), but good luck trying to convince kdepim devs of that :) Heh. Distros can always opt out of b) and patch it to a) ;). Though I'm not sure I understand the concern. If pim devs don't pay attention to the ABI then in what scenario would a distro not rebuild everything? Or I guess to preempt the answer a bit, if distros can tell if ABI was broken, why can't we, KDE, and bump the version when that happens. The bottom line here is that proper so versioning is not the same as ABI stability. Just because pim doesn't care about ABI stability doesn't mean we should release clearly incorrectly versioned libraries. In particular when even our own software outside the release-service is using it, so the "oh but this library is not for third parties" excuse doesn't even fly here :| -- You are receiving this mail because: You are watching all bug changes.
