I have recently been looking into backporting a fix for variable-length
metadata fields from master to branch-2.7. Unfortunately, the fix makes several
changes to libopenvswitch APIs, in particular some files under
include/openvswitch/*.h and lib/*.h. From the perspective of the
openvswitch-dev packages, these are visible in
/usr/include/openvswitch/{,lib/}*.h.This is the series: https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329811.html To backport these changes, they would introduce a breakage to the libopenvswitch ABI, in contrary to the policy outlined here: http://docs.openvswitch.org/en/latest/internals/contributing/libopenvswitch-abi/ Normally, library developers may advertise ABI-breaking changes by including libtool tags in their .so files, where the "current" number indicates that the interface changed in a backwards-incompatible manner. OVS currently maintains this "current" number as the same as the minor release number in an OVS release, for example "Y" in the OVS X.Y.Z release. We have a few options: * Don't backport the fix. The issue will exist, unfixed, in v2.7. * Backport the fix and ignore the ABI breakage. This is not nice for users, as they may update their OVS packages and then begin to observe weird behaviour in programs that dynamically link against those libraries. * Backport the fix and modify current, for example for 2.7 to use "8" as the "current" number. This would however conflict with the upcoming 2.8 release, so the "current" number would need to be modified to something else for that release. Result for users of libopenvswitch would be that the programs fail to dynamically load, because the libtool library version indicates that the newly updated OVS library is incompatible with the version that their application was compiled against. This is nicer than the previous option. * Attempt to find an alternative workaround, for instance by developing a new set of patches which disable functionality that triggers the bug, or by attempting to fix the underlying issue in a fundamentally different manner from the way it is fixed on master. This includes risk as the changes will not receive pre-release testing through developers running the code from the master branch. In the past, developers have not paid particularly close attention to changes to lib/*.h header files. Bugfixes which change these have been applied to master (this is OK), then backported to branches 2.6 and 2.7 without attempting to avoid changes to the header files (this is in contrary to the policy above). As such, there has been ABI breakage between v2.6.0...branch-2.6, and v2.7.0...branch-2.7. In this particular case it appears that if the issues are to be fixed on v2.7, then changes to include/openvswitch/*.h are necessary, and therefore we should export this ABI breakage through the libtool "current" number. There is currently no method to do this cleanly, as the libtool "current" number is tied to the OVS minor release number. This series proposes to change the name of the libopenvswitch-X.so.Y.0.Z library to become libopenvswitch-X.Y.so.CURRENT.0.Z, where X, Y, and Z correspond to the OVS release number, for example 2.7.0; and CURRENT is the libtool current number, which would begin as 0 for every libopenvswitch-X.Y release, and would be incremented whenever backwards-incompatible changes are introduced. The policy would remain that we make first efforts to avoid changing the "current" libtool number within an OVS release series; and if this is not viable or possible, developers may submit ABI-breaking changes along with an update to this "current" libtool number. If this is reasonable, I would also seek to backport this to branch-2.7. I don't have a good understanding of the impact of such a change on libopenvswitch users, so I would welcome anyone building applications upon this to voice their feedback. TL;DR: Is it reasonable to change the libopenvswitch library name to include MAJOR.MINOR release number? Joe Stringer (2): libopenvswitch: Rename to libfoo-X.Y. configure: Reset libtool CURRENT version. .../internals/contributing/libopenvswitch-abi.rst | 16 +++++++++------- configure.ac | 2 +- m4/openvswitch.m4 | 6 +++--- 3 files changed, 13 insertions(+), 11 deletions(-) -- 2.11.1 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
