ABI stability of internal DBs

[Stefan (metze) Metzmacher]

Hi Volker,

> On Wed, Jul 07, 2010 at 11:20:22AM +0200, Stefan (metze) Metzmacher wrote:
>>> Ok, so you are proposing that for all our internal databases
>>> like locking.tdb we create stable APIs like libwbclient,
>>> along with the messaging protocols, which need to be
>>> encapsulated similarly?
>>
>> No, only for things which need to be accessed by other applications.
>>
>> For internal things we just need to support for 2 versions
>> of a protocol or db format, how we do that doesn't
>> matter...
> 
> That's exactly the testing nightmare that I tried to lay out
> earlier. We can do that, but this will slow us down
> tremendously. If we make that promise, we will potentially
> have to support n different versions. Vendor A will require
> the upgrade from 3.3.10 to 3.5.4, Vendor B will require the
> upgrade from 3.4.7 to 3.6.1. Vendor C will step in with yet
> another combination.

I thought this would be limited like this:
All 3.B.x versions will use the same formats and features.
And they only need to support upgrades from 3.A.x versions.

If someone needs to upgrade from 3.3.10 to 3.5.4, it's needed
to first upgrade to 3.4.8, before upgrading to 3.5.4.

> If that is our decision from now on, we will need MUCH
> better review of all changes. Mandatory tests for the
> upgrade procedures and tests with running clusters with the
> promised upgrade versions will need to be designed.
> 
> I wonder who will provide the resources for this testing
> infrastructure. RedHat? IBM? SuSE? Other vendors with
> clustered Samba?

I'm not proposing that we give such a promise. I'd actually like to
avoid it.

I just explained a possible technical solution, which would still be a
hell lot of work.
And I guess we're not able to handle it with our current resources.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100707/8af21917/attachment.pgp>