libsyslog-ng versioning

[algernon]

Currently, we set the soname of the library to libsyslog-ng-$VERSION, which means that third party modules will have a tight dependency on the syslog-ng version, even if the library does not change incompatibly between bugfix releases.

To remedy the issue, I would suggest using a soname like libsyslog-ng-${MAJOR_VERSION}-${ABI_LEVEL}, where we bump ABI level each time the library changes incompatibly. We'd only do this for stable releases, obviously, alphas and betas would use libsyslog-ng-${MAJOR_VERSION} without an ABI level.

The advantage of this is that Incubator binary packages are not so tightly coupled to syslog-ng versions.

As a side effect, Debian packaging will need to move the modules from /usr/lib/syslog-ng/$VERSION to /usr/lib/syslog-ng/$MAJOR_VERSION.

[bazsi]

Hi,

Well, this might be a good thing, however the core library is not
necessarily designed with ABI stability in mind. Changing a struct anywhere
renders incompatible changes, enums are quite regularly shifted to make
another slot free.

I'm not saying it's impossible, I just think that the API between the core
and the modules is quite broad and information hiding was not a design
constraint.

Cheers,
Bazsi

On Thu, Aug 7, 2014 at 4:00 PM, Gergely Nagy notifications@github.com
wrote:

Currently, we set the soname of the library to libsyslog-ng-$VERSION,
which means that third party modules will have a tight dependency on the
syslog-ng version, even if the library does not change incompatibly between
bugfix releases.

To remedy the issue, I would suggest using a soname like
libsyslog-ng-${MAJOR_VERSION}-${ABI_LEVEL}, where we bump ABI level each
time the library changes incompatibly. We'd only do this for stable
releases, obviously, alphas and betas would use
libsyslog-ng-${MAJOR_VERSION} without an ABI level.

The advantage of this is that Incubator binary packages are not so tightly
coupled to syslog-ng versions.

As a side effect, Debian packaging will need to move the modules from
/usr/lib/syslog-ng/$VERSION to /usr/lib/syslog-ng/$MAJOR_VERSION.

—
Reply to this email directly or view it on GitHub
#190.

[algernon]

I kept that in mind, hence why we'd always have a part of the soname tied to the syslog-ng version, and only attempt doing something resembling a stable ABI when the branch sees its first release. There were, I think, only three ABI breakages since 3.5.0rc2 on the 3.5 branch, for example. And with a little more care, I'm pretty sure I can get that down to zero with 3.6.

So, while a branch is under development, there will be no ABI guarantees, and the soname would remain the same, even in the face of breaking changes. Once it enters RC, changing structs and reordering enums becomes a very, very rare thing. And then, we can do a little better versioning.

[bazsi]

ok. understood.

On Thu, Aug 7, 2014 at 9:57 PM, Gergely Nagy notifications@github.com
wrote:

I kept that in mind, hence why we'd always have a part of the soname tied
to the syslog-ng version, and only attempt doing something resembling a
stable ABI when the branch sees its first release. There were, I think,
only three ABI breakages since 3.5.0rc2 on the 3.5 branch, for example. And
with a little more care, I'm pretty sure I can get that down to zero with
3.6.

So, while a branch is under development, there will be no ABI guarantees,
and the soname would remain the same, even in the face of breaking changes.
Once it enters RC, changing structs and reordering enums becomes a very,
very rare thing. And then, we can do a little better versioning.

—
Reply to this email directly or view it on GitHub
#190 (comment).