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

[Simo]

On Mon, 2015-03-16 at 21:01 +0100, Jelmer Vernooij wrote:
> 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).

The middle ground is still private libraries with no promises, but we
pay a little bit more attention and try to warn known users when we
change them. They still are private interfaces with no promises for any
random user.

Simo.

-- 
Simo Sorce