ABI stability of internal DBs

[David Collier-Brown]

Stefan (metze) Metzmacher wrote:
> 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
>
>   
While I'm a versioning bigot (;-)), no version system will work if the
external customers and suppliers won't honor it.   In particular, if a
single vendor of Samba freezes at 3.8.19, you'll have to either maintain
that version until they decide to unfreeze or stop supporting them.

This is a recurring problem with "enterprise" systems where a vendor
commits to their customers to support something for 5-8 years.  They
implicitly agree to maintain everything they get from elsewhere (i.e.,
Samba) in the same manner.
Of course, they try to avoid having to actually do the work, by
insisting that their suppliers  maintain 3.8.19 for five years (:-()

They indeed need to step up to the plate and take over at least the test
infrastructure for the versions they freeze on.

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-8968