ABI stability of internal DBs

[Andrew Bartlett]

On Tue, 2010-07-06 at 23:44 -0400, simo wrote:
> On Tue, 2010-07-06 at 18:28 -0700, Jeremy Allison wrote:
> > On Mon, Jul 05, 2010 at 09:50:38AM -0400, simo wrote:
> > > 
> > > As far as I know we haven't decided about such a policy, but now that
> > > you better described the issue, I wonder if we should discuss if such a
> > > policy makes sense and if we should try to adopt one.
> > 
> > Not for this kind of case IMHO.
> 
> I tend to agree.
> 
> > > But before even thinking of a database format compatibility rule we need
> > > to understand if we can achieve this goal of allowing rolling upgrades
> > > between one major version and the next. If we can't for other reasons
> > > that go beyond the mere database format, then it doesn't make sense to
> > > try to keep the db formats stable either.
> > 
> > I don't think allowing such rolling updates is possible, and
> > still allow us to add the features needed to keep Samba (non-clustered)
> > moving forward in a timely fashion.
> 
> Again, I said major but I meant Y version in the X.Y.Z scheme we have.
> I guess we can keep guarantees that if I upgrade from 3.5.z to 3.5.z+n
> it will not break things ?

If we do propose such a requirement, then we need something like the ABI
checker to enforce it, or else such rules will be forgotten, and our
promises will mean nothing.  

But even if we keep the structures the same size, we could change the
behaviour based on those structures.  All of our testing is done with
only the exact same version, and certainly not the cross-product of all
the release versions, so I would argue any cross-version compatibility
is completely untested. 

Should we be making such untested promises to exactly the users who need
a highly reliable Samba?  If so, how can we provide (other than of
course the due care and attention when making changes in the release
stream) meaningful assurances here?

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/20100707/0d6e66a5/attachment.pgp>