Hi Aaron, > On Jan 5, 2017, at 7:52 AM, Aaron Conole <[email protected]> wrote: > > <snip> > >>>> Should we bump the libtool version now? We're nearing a release, so >>>> it's about the right time. >>> >>> Sorry for the late response. I think it's probably appropriate to bump >>> at least the libtool 'age'. I'm not sure what kinds of ABI changes have >>> happened since introduction though - the interface 'major' version may >>> need to change. >> >> I'm pretty sure we've busted ABIs left and right since 2014, so a major >> version update should be appropriate. > > I was about to post a patch that simply bumped this version, but it sent > me off onto a tangent leading to this question: > > Will Open vSwitch support the libopenvswitch.so as an externally > linkable library? > Yes, as an example Debian now has a ‘openvswitch-dev’ package that bundles the library and header files. Here’s how it currently looks (Debian ‘sid’):
ben@ben-lab-sc1:~$ dpkg -c openvswitch-dev_2.6.2-pre+git20161223-2_amd64.deb | grep "lib.*\.so" lrwxrwxrwx root/root 0 2016-12-23 16:35 ./usr/lib/libofproto.so -> libofproto.so.1.0.0 lrwxrwxrwx root/root 0 2016-12-23 16:35 ./usr/lib/libopenvswitch.so -> libopenvswitch.so.1.0.0 lrwxrwxrwx root/root 0 2016-12-23 16:35 ./usr/lib/libovn.so -> libovn.so.1.0.0 lrwxrwxrwx root/root 0 2016-12-23 16:35 ./usr/lib/libovsdb.so -> libovsdb.so.1.0.0 lrwxrwxrwx root/root 0 2016-12-23 16:35 ./usr/lib/libsflow.so -> libsflow.so.1.0.0 lrwxrwxrwx root/root 0 2016-12-23 16:35 ./usr/lib/libvtep.so -> libvtep.so.1.0.0 > I know there was some work done in this direction, but nothing for ABI > versioning or API compatibility has been done yet. > As you can see, the library naming isn’t very useful. As for ABI versioning, I don’t think anything meaningful has been done. IMHO we should probably change this so the major release is part of the name, since that’s where I believe we should guarantee compatibility, along the l lines of ‘libopenvswitch_2.5.so’ or whatever. I think there are libtool directives for managing this naming, but we haven’t done that. > I've CCd folks who were on the original discussions for the various > series I've found (linked below). > > I'm uncomfortable with bumping this and just 'let the chips fall where > they may,' since having a version that hasn't changed is the virtually > the same as not having a version. The instant we bump, we state that > the version means something, so I'm not comfortable just shipping a > patch that changes the version without some accompanying documentation > explaining *what* that means. It also means we need to be more diligent > with reviews and watch for potential ABI breakages, with a compatibility > strategy in place (when ABI/API changes can be made, how they are made, > etc.). I think it's got more implication than just a single line change > to the configure.ac file. > > Below are a few snippets I found; there may be more discussions I've > missed, so please feel free to include links (or summaries). > > Versioning patch (which mentions that it isn't yet intended to be for > 3rd party linking): > https://mail.openvswitch.org/pipermail/ovs-dev/2014-November/291959.html > > The first non-rfc 'third-party linking' series I could find (with note > from Panu at least warning about this): > https://mail.openvswitch.org/pipermail/ovs-dev/2016-March/310703.html > https://mail.openvswitch.org/pipermail/ovs-dev/2016-March/310773.html > > The series 'third party linking' series has all parts accepted: > https://mail.openvswitch.org/pipermail/ovs-dev/2016-April/313183.html > > -Aaron
_______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
