On Sat, 4 Feb 2006, 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).
>
Hrm!?! Some time ago, I revised the notification API to use a struct
instead of lots of parameters just so we could add more in the future if
needed. The reason was to add some field when we implemented locking. If
you call that a "little API revving", then go look for that diff...
Also, what about our version check macros? Don't they protect applications
from such badness?
Regards,
//Peter
---------------------------------------------------------------------
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:32:14 2006