On Tue, Dec 15, 2009 at 1:21 PM, William A. Rowe Jr. <[email protected]> wrote: > [email protected] wrote: >> >> The previous paragraph acknowledges that we aren't worried if somebody >> codes against in-flux APIs in that apr-util packaged with httpd 2.3.4. >> What is the problem scenario here? How can the exchange of >> apr-util-1.4.0-dev with apr-util 1.4.1 hurt unless the user has some >> code that relies on in-flux APIs? > > On some platforms (windows) the library will fail to load if the number > of args to an apr_fn(x,y,z) signature change. Win32, for example, will > decorate the link symbols with the number of bytes of stack args, e.g. > apr_initialize is 'apr_initial...@0'. But on most platforms, such a > change in the number of args is silently harmful. > > Similarly, for Graham's work on the apr_crypto_t structure, moving the > apr_crypto_driver_t element or adding the *error pointer in the middle > of the existing declarations will silently slaughter a provider compiled > under 1.4.1+++ but running under 1.4.0-dev.
I thought that was covered by "Paul and I agree that we shouldn't be working to accommodate a *developer* who programs against an API that shipped by httpd labeled '-alpha'. It wasn't an apr-util release, they shouldn't have any such expectations."
