>[EMAIL PROTECTED] wrote: >> We have been down this road before. There is a reasonable expectation that >> extensions may differ subtly from extension to extension. I see no need to >> fork my source for 4.0.x and 4.1.x compatibility when it is simple enough to >> do with macros and maintain one source file.
>... and with #ifdefs all over the place it becomes a complete mess, >even now with only two different api versions supported >maintainance of older releases is what we have CVS branches for, >we have more than enough #ifdef's in the code (due to configure detected >stuff and threaded server support), i see no need to have even more >of those in situations where we have other means to deal with Removing backward compatibility for aesthetic reasons is bogus. To be perfectly honest, I think the whole PHP extension API is truly ugly. The removal of a few #ifdefs will not a Mona Lisa make. Just because "you" do not see a reason, does not mean that "I" do not see a reason. Having one version of a source module is almost always better than two versions with a fork. I have servers that run 4.0.6, they need msession and they need msession development. I wish to make sure that msession is available to those who can use it, and I wish to continue developing new features. I am not going to develop and merge two versions every single time I make a change. I just don't understand the attitude. Why do you care? What harm does it do? How does my keeping backward compatibility in an extension negatively affect PHP? What is the issue? (Aesthetics aside, of course.) -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
