[PATCH] passdb: Increase ABI version to 0.28.0

[Lukas Slebodnik]

On (07/03/19 09:08), Jeremy Allison wrote:
>On Thu, Mar 07, 2019 at 12:20:37PM +0100, Andreas Schneider wrote:
>> On Thursday, March 7, 2019 9:49:13 AM CET Lukas Slebodnik via samba-technical 
>> wrote:
>> > On (06/03/19 15:12), Jeremy Allison wrote:
>> > >On Wed, Mar 06, 2019 at 03:01:19PM -0700, Christof Schmitt via samba-
>> technical wrote:
>> > >> Past changes of this library versions have been done by incrementing the
>> > >> second number as "major" and the third as "minor". My guess is that the
>> > >> leading 0 tries to state that this is not necessarily a stable API.
>> > >> 
>> > >> You are correct that this does not conform to the normal handling of
>> > >> library versions. The question is whether we stick to the old scheme for
>> > >> now and discuss library versioning separately; or whether passdb should
>> > >> become 1.0.0 now. I would like to hear other opinions on this topic.
>> > >
>> > >Oh, when you put it like *that* :-). passdb should certainly
>> > >*not* be at 1.0.0 :-).
>> > >
>> > >OK, fair enough. Let's leave it at 0.28.0 for master.
>> > 
>> > Could you explain why ?
>> > 
>> > You have to bump SONAME because of backward incompatible change in public
>> > library especially for master.
>> > 
>> > If you want you can have 1.28.0 and not 1.0.0 that's just tiny detail IMHO
>> 
>> Lukas is right. The SO version is MAJOR.MINOR.PATCH
>> 
>> MAJOR needs be bumped if you have an API incompatible change, e.g. removing a 
>> functions which was public before.
>> 
>> MINOR needs to be bumped if you add something to the public API, add a value 
>> to an enum, new function, new define etc.
>> 
>> PATCH is increased if only a code change and the API did not change in any 
>> way.
>> 
>> 
>> So if you remove a function you need to bump the MAJOR so we will get 1.0.0!
>
>Problem is passdb isn't really an externally supported API for
>general use. It's not the case that it gets wide usage or traction
>like our VFS libraries, talloc or tevent.
>
>I completely agree with your ideas on these libraries, we
>fully externally support stabe API/ABI's here.
>
>I don't *want* it to be an external ABI that other projects
>depend on, certainly not without much more thought and revisions.
>

That's fair and I know that keeping API/ABI stable is not trivial task.

One solution is to make library private and another one is do not promise
stability and bump SONAME with any backward incompatible change.

But all libraries which are installed in standard library path should be
considered as public and thus follow best practices.

Here is a list from samba-libs-4.10.0-0.2.rc2 which is in fedora rawhide

sh# rpm -ql samba-dc-libs samba-client-libs samba-libs | grep lib64/lib | sort
/usr/lib64/libdcerpc-binding.so.0
/usr/lib64/libdcerpc-binding.so.0.0.1
/usr/lib64/libdcerpc-samr.so.0
/usr/lib64/libdcerpc-samr.so.0.0.1
/usr/lib64/libdcerpc-server.so.0
/usr/lib64/libdcerpc-server.so.0.0.1
/usr/lib64/libdcerpc.so.0
/usr/lib64/libdcerpc.so.0.0.1
/usr/lib64/libndr-krb5pac.so.0
/usr/lib64/libndr-krb5pac.so.0.0.1
/usr/lib64/libndr-nbt.so.0
/usr/lib64/libndr-nbt.so.0.0.1
/usr/lib64/libndr.so.0
/usr/lib64/libndr.so.0.2.0
/usr/lib64/libndr-standard.so.0
/usr/lib64/libndr-standard.so.0.0.1
/usr/lib64/libnetapi.so.0
/usr/lib64/libsamba-credentials.so.0
/usr/lib64/libsamba-credentials.so.0.0.1
/usr/lib64/libsamba-errors.so.1
/usr/lib64/libsamba-hostconfig.so.0
/usr/lib64/libsamba-hostconfig.so.0.0.1
/usr/lib64/libsamba-passdb.so.0
/usr/lib64/libsamba-passdb.so.0.27.1
/usr/lib64/libsamba-util.so.0
/usr/lib64/libsamba-util.so.0.0.1
/usr/lib64/libsamdb.so.0
/usr/lib64/libsamdb.so.0.0.1
/usr/lib64/libsmbconf.so.0
/usr/lib64/libsmbldap.so.2
/usr/lib64/libtevent-util.so.0
/usr/lib64/libtevent-util.so.0.0.1

LS