On Tue, 2021-11-30 at 21:28 +0100, Martin Wilck wrote: > On Tue, 2021-11-30 at 10:52 -0600, Benjamin Marzinski wrote: > > On Mon, Nov 29, 2021 at 09:52:49PM +0100, Martin Wilck wrote: > > > I agree. Also, I realize that we've bumped the library version > > > too > > > often in the past. If we add a function, we don't need to bump. > > > Because > > > a program that needs the added function will require e.g. > > > foo@LIBMULTIPATH_10.0.0, and this will fail for a library that > > > doesn't > > > export foo (which is what we want). Likewise for function > > > deletion > > > - a > > > program that calls the deleted function will fail to link with > > > the > > > updated library. OTOH, programs that use this version of the ABI > > > *without* using the functions which are added or removed are > > > unaffected > > > by the addition / removal. > > > > > > The only case in which the ABI version must be bumped is when we > > > have > > > changed functions or data structures. > > > > > > Furthermore, I believe now that the habit (which I introduced) to > > > list > > > added functions at the end of the .version files, with comments > > > indicating when they were added, is useless. We should rather > > > keep > > > the > > > .version file ordered alphabetically. > > > > So we not use the minor version anymore? > > Perhaps we'll encounter another use case for it, or we find a flaw in > my reasoning above. I wouldn't remove the digit. And here's the flaw: While my argument above is valid for ld.so, it's not for package management tools like rpm. Here on openSUSE, we got rpm Requires like "libmultipath.so.0(LIBMULTIPATH_13.0.0)(64bit)". As distributors, we prefer incompatibilities to be detected at installation time rather than at runtime. So, we do need the minor version bumps. Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
