unversioned public libraries in Samba (was: Re: ntdb in Samba?)

[Jelmer Vernooij]

On Mon, Mar 16, 2015 at 03:40:10PM -0400, Simo wrote:
> On Tue, 2015-03-17 at 08:31 +1300, Andrew Bartlett wrote:
> > On Mon, 2015-03-16 at 09:07 +0100, Michael Adam wrote:
> > > On 2015-03-16 at 07:57 +0100, Volker Lendecke wrote:
> > > > On Mon, Mar 16, 2015 at 01:13:23PM +1300, Andrew Bartlett wrote:
> > > > > On Sat, 2015-03-14 at 15:07 +0100, Volker Lendecke wrote:
> > > > > > On Sat, Mar 14, 2015 at 01:14:31PM +0100, Michael Adam wrote:
> > > > > > > On 2015-03-13 at 20:51 +0100, Volker Lendecke wrote:
> > > > > > > > On Fri, Mar 13, 2015 at 06:01:42PM +0100, Michael Adam wrote:
> > > > > > > > > Excellent idea.
> > > > > > > > > 
> > > > > > > > > I also find it regrettable that the proposed git tree has been
> > > > > > > > > withdrawn so fast..
> > > > > > > > 
> > > > > > > > My point is that we need a better communication strategy about which
> > > > > > > > pieces of Samba we want to take the liberty to change without notice
> > > > > > > > and which pieces we stick to.
> > > > > > > 
> > > > > > > That is easy (and has been stated several times):
> > > > > > > All components that are not explicitly flagged as
> > > > > > > published APIs/libraries can be changed by us at will.
> > > > > > > External consumers will have to adapt.
> > > > > > 
> > > > > > So every SAMBA_LIBRARY without private_library=True and with
> > > > > > a vnum= is a published API? 
> > > > > 
> > > > > Yes, that is exactly the rule.
> > > > 
> > > > This will make it practically impossible to refactor
> > > > internals, but thanks for this information.
> > > 
> > > The question here is what it means to have a published, or
> > > as I would even prefer to put it, a versioned API.
> > > 
> > > My idea from my last mail still stands, that I think that we of
> > > course can still change and refactor these systems at will, but
> > > but that we should keep updating the vnum as an indication of
> > > need for adaption of consumers.
> > > 
> > > IMHO, that's the only promise attached to that.
> > > Everything else is pure niceness.
> > 
> > Indeed, there is a big difference between:
> >  - not public APIs (vfs.h is one of these, ouch)
> >  - public APIs
> >  - promised API
> >  - promised ABI
> > 
> > Because in the past, we didn't do so well with providing anything more
> > than a published API, we imposed some restrictions on some of our
> > libraries, in particularly the independently buildable libraries.  Even
> > within those, we have different rules - we do not make ABI promises
> > about things within ldb_module.h, for example.
> > 
> > We make no promises about some of these, but metze in his reply
> > describes well the best practices in this area, because we like to be
> > good to our friends, as that keeps the whole ecosystem strong.
> 
> There is a big difference between libraries and modules.
> 
> VFS are modules, like ldb modules run inside samba, it is really better
> if you get them into the main code, but otherwise you have to accept
> that you have to deal with changes on upgrades. This is pretty common
> practice, although more mature projects at least try to have a module
> interface version so the module fails to load on interface changes
> rather than just break at dynamic linking time (or worse ...)
> 
> Other libraries that are used by external programs are quite different,
> and here having semi-private libraries benefits no one. We should have
> public libraries with ABI promises or private libraries with no ABI
> promises whatsoever. I do not think a middle-ground does any good to
> anyone as it would just be a lie.

Agreed, for stable releases.

I think the middle ground does have its place. The middle ground was a
good promise when things were still evolving, and when it wasn't clear
what functionality was needed by outside parties like OpenChange
(which was itself very much in flux at the time).

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - https://jelmer.uk/