Hi Joe,
Some stream-of-consciousness thoughts follow, sorry if it's a bit
disconnected.
Joe Stringer <j...@ovn.org> writes:
> 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.
This is definitely not something we want.
> * 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.
+1, I don't know that we want this either.
> * 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.
The neat thing with this solution, though, is it doesn't break existing
applications by installing the software. The older libopenvswitch bits
are still available at 2.so.7, but it means a disconnect between
openvswitch version, and the library naming.
> * 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.
Agreed here, but we can try to mitigate this risk - possibly with
improved tests. It won't beat having lots of diverse soak time, but at
least it will be something.
That said - I don't know what the right answer is. Maybe this is the
reason to have the long-term support distinction. Maybe the policy is
that for LTS releases, we actually promise NEVER to break ABI, and
instead figure out a more complicated backport that allows applications
to rely on a stable ABI (even if the api has to change). Just
brainstorming ideas.
> 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.
To this end, I've got something quickly cooked up. I'd like to
integrate it with something - maybe travis - do you think it's
worthwhile?
https://gist.github.com/orgcandman/95c3129f677be0483daac437853c4071
At least we'd be aware that we are going to 'break' something, and can
plan accordingly.
> 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'm not sure how that works in libtool - I'd need to look at the
documentation. It doesn't sound unreasonable, though.
> 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?
I'm okay with it. Getting the policy right is more important than the
naming bits. :-)
> 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(-)
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
