On 2019/07/20 05:09, Jonathon Sisson wrote: > On Sat, Jul 20, 2019 at 12:45:25PM +0100, Stuart Henderson wrote: > > On 2019/07/20 04:05, Jonathon Sisson wrote: > > > Hello, > > > > > > Here is a diff to update protobuf to 3.9.0. > > > > > > PLIST adjusted for singleton.h and wire_format_lite_inl.h removal. > > > > > > Tested on amd64. I lack the hardware to test on arm64 (looking for > > > suggestions...Rock64?). > > > > Almost certainly all the shared library major versions need bumping for > > this update. > > > > What have you done in the way of testing ports that depend on this? > > (https://openports.pl/path/devel/protobuf, click "reverse dependencies") > > > Testing was with umurmur by way of protobuf-c. > > I'll return to the porting guide and read up on library major version bumps. > > Jonathon >
In a nutshell: if you don't touch the library version (in SHARED_LIBS which then makes it through to the library name libfoo.so.X.Y), you are claiming that the new library and old library are fully interchangeable: if you have an installed program that was built against the old library+headers, you can just update the library to the new version without recompiling the program and everything will still work (and vice-versa with a new-compiled program and an old library). If any function was removed in the new version, or the prototype was changed - e.g. "function(int a, int b)" changed to "function(long a, long b)" or "function (int a)" - then a program compiled for the old version of the library will no longer work. In this case the major version (X from .so.X.Y) must be bumped. Additionally if members of a struct were changed then in many cases there is no compatibility in either direction and again major must be bumped. (This is hard to spot without either using compatibility checking tools, or comparing diffs of source trees). If any function was *added* in the new version, but no existing function was changed/removed and structs are all compatible, old programs can be used with the new library, so no major bump is needed. But new-compiled programs *might* use that new function, so the minor (Y from .so.X.Y) is bumped to prevent them running with the old library. These version numbers are used both to ensure that the correct library is used for a particular program, and to trigger updates in pkg_add, so it's important to either get things right, or err on the side of unnecessary bumps, otherwise things will break for users. In this case looking at the diff between the list of functions in old+new library versions it's thousands of lines (this is quite often the case for C++ libraries) and the chances of old binaries working with new library are very low. This is also useful: https://abi-laboratory.pro/?view=timeline&l=protobuf
