-----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).
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFD5Mv2fFNSmcDyxYARAt73AJ0d/lXpmiKCK25DUkCX4qZ9V83bRACeKpm8
RAxmUT1S+pFjpk+nX322gOQ=
=0xZx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 4 16:45:18 2006