Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Julian Foad wrote:
>
>> Peter N. Lundblad wrote:
>>
>>> On Thu, 2 Feb 2006, Julian Foad wrote:
>>>
>>>> Peter N. Lundblad wrote:
>>>>
>>>>
>>>>> I don't understand the above. If we forbid users to allocate this
>>>>> struct,
>>>>> we can freely add fields in the future without problems. Or do you
>>>>> mean
>>>>> that we have a rule that if you compile with library x+1, and it links
>>>>> with lbirary x, it should work? Is that what you mean by "forward
>>>>> compatibility"?
>>>>>
>>>> Yes, that's what I meant.
>>>>
>>> Is that really something we need to care about? If you link against
>>> 1.4.17
>>> and then, at runtime, use 1.3.4, could you expect that to work, then? I
>>> don't think we leave such guarantees.
>>>
>> Ah, yes, you're right. An application for 1.4.x libraries is not
>> expected to work when run with 1.3.x libraries, so we can add extra
>> fields in the next minor version, and don't care that an application
>> using them won't work if run with older libraries.
>>
>> The difference from our normal API compatibility process is that in this
>> case the incompatibility won't be detected at link time. If a
>> particular application uses some features of the new library, but only
>> ones of this kind, then it will load and start to run against old
>> libraries but with undefined behaviour. I don't know whether we want to
>> care about that.
>>
>
> Ouch! Even if this is permissible by a strict semantic reading of the
> compat rules, do we really want to create such a situation?
>
> Currently, the situation is that any compatibility problem will sooner
> or later trigger some kind of symbol-not-found error - a situation which
> allows for moderately graceful failure.
>
> I don't think it does either us, or the clients of our libraries, to
> avoid a little API revving if the cost is the potential for obscure and
> hard-to-detect bugs. I suggest simply contracting to rev the API
> whenever the structure changes (it's not that hard, after all).
>
We have version checks that enforce the compatibility rules.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 4 22:21:36 2006