Clarify module ABI stability #920

New Issue

2026-10-05T04:52:43+02:00

adam commented

2026-10-05 04:52:43 +02:00

Hi,

It would be great for ZNC to track the stability of its plugin ABIs. The lack of ABI versioning forces downstreams to set very strict dependencies, with the resulting problem that any znc change needs rebuilds of plugins. See for example debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917222

Keeping track of which changes are ABI compatible is not really easy with c++ libraries (see these KDE guidelines for example). Thus, I propose to be overly conservative and assume that everytime a header file changes, the versioning should be bumped. This would allow downstreams to relax module dependencies a little bit.

Thanks

Hi, It would be great for ZNC to track the stability of its plugin ABIs. The lack of ABI versioning forces downstreams to set very strict dependencies, with the resulting problem that any znc change needs rebuilds of plugins. See for example debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917222 Keeping track of which changes are ABI compatible is not really easy with c++ libraries (see [these KDE guidelines](https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts) for example). Thus, I propose to be overly conservative and assume that everytime a header file changes, the versioning should be bumped. This would allow downstreams to relax module dependencies a little bit. Thanks

adam commented

2026-10-05 04:52:44 +02:00

I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916764 is a better link.

We attempted this already, and failed. #1353 has more details, including links to more ABI-related issues.

I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916764 is a better link. We attempted this already, and failed. #1353 has more details, including links to more ABI-related issues.

adam commented

2026-10-05 04:52:44 +02:00

The lack of ABI versioning forces downstreams to set very strict dependencies, with the resulting problem that any znc change needs rebuilds of plugins.
[...]
Thus, I propose to be overly conservative and assume that everytime a header file changes, the versioning should be bumped.

Am I missing something or is your proposal pretty much equivalent to the status quo? (but requires extra work since there would be an explicit ABI version number that needs to be bumped all the time?)
There are not many ZNC versions that do not differ in at least some header file, I think.

> The lack of ABI versioning forces downstreams to set very strict dependencies, with the resulting problem that any znc change needs rebuilds of plugins. [...] > Thus, I propose to be overly conservative and assume that everytime a header file changes, the versioning should be bumped. Am I missing something or is your proposal pretty much equivalent to the status quo? (but requires extra work since there would be an explicit ABI version number that needs to be bumped all the time?) There are not many ZNC versions that do not differ in at least some header file, I think.

adam commented

2026-10-05 04:52:45 +02:00

Am I missing something or is your proposal pretty much equivalent to the status quo? (but requires extra work since there would be an explicit ABI version number that needs to be bumped all the time?)
There are not many ZNC versions that do not differ in at least some header file, I think.

It would be mostly the same if the header files change all the time. It would make a bigger difference if they didn't change so often.

> Am I missing something or is your proposal pretty much equivalent to the status quo? (but requires extra work since there would be an explicit ABI version number that needs to be bumped all the time?) > There are not many ZNC versions that do not differ in at least some header file, I think. It would be mostly the same if the header files change all the time. It would make a bigger difference if they didn't change so often.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#920