ABI stability of internal DBs

Andrew Bartlett abartlet at samba.org
Mon Jul 5 06:47:05 MDT 2010


On Mon, 2010-07-05 at 10:00 +0200, Volker Lendecke wrote:
> On Sun, Jul 04, 2010 at 06:20:29PM -0400, simo wrote:
> > On Sun, 2010-07-04 at 14:49 -0500, Volker Lendecke wrote:
> > > commit 23a31becacee9da11ebe4dff4a3146e19c95a5be
> > > Author: Volker Lendecke <vl at samba.org>
> > > Date:   Sun Jul 4 20:45:43 2010 +0200
> > > 
> > >     s3: Remove unused msg_flags from connections.tdb
> > >     
> > >     This breaks rolling code upgrade!
> > 
> > I guess this is because you removed the msg_flags entry from
> > conenction_data.
> > 
> > Can't we simply rename the field to uint32_t unused and retain
> > compatibility ?
> > 
> > Or would that cause issues I don't see right now ?
> 
> So we are at the point that we can never change internal
> databases anymore?
> 
> This is a new policy that I was not aware of, sorry.

Volker,

I am also unaware of any such policy, and I think that we should
carefully discuss the implications of any such policy.  The challenge
with freezing any ABI is that it is cheap to implement, but potentially
quite costly in the long term.  We should ensure that we don't set up
long-term costs without a matching long term benefit (such as external
users of a published library ABI). 

In terms of databases, I would hope we do not adopt such a policy,
because I would likewise like the freedom to propose changes to Samba
internal structures, some of which may touch this kind of internal DB. 

In this particular case, indeed it may have been easy to keep
compatibility, but I join you in the fear for the precedent this sets. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100705/eb6d340d/attachment.pgp>


More information about the samba-technical mailing list