On Sat, Mar 29, 2003 at 06:59:47PM -0800, Kurt D. Zeilenga wrote: > Well, as I noted before, option (b) is problematic as that > would require applications which avoided the experimental > code to be rebuilt in order pick up important bug fixes > to non-experimental code. Good point. Did not read that mail, I lost my hard drive a few days before, therefore the mail of a few days has gone by unnoticed. > And I think (a) is bad as code is broken and, to date, no > one has demonstrated any desire to fix the broken code. (If > someone actually provided patches which fix the broken code, > then (a) would obviously be reasonable option.) > > So, I'd suggest another option, include the shell functions > in the next 2.1 "incremental" release (but not 2.2, our next > "full" release) which were previously provided when caching > was not enabled. This will resolve the linking issues without > reintroducing broken code, but does nothing to fix the broken > applications which expected caching to be enabled by default. So you will introduce replacement functions that simulate the removed functions for broken application? That sounds great. Regarding the broken code: May I suggest adding a warning message to those functions that every app using them informs the user that it has to be fixed by printing something like WARNING: Call to obsolete function ldap_enable_cache. Perhaps with the possibility to switch it on/off using an environment variable. Otherwise people might not notice that their app will break soon. Thanks Torsten
Attachment:
pgp5ydweUHont.pgp
Description: PGP signature