Well. You know my opinion. And you can't compare PHP versions with library versions. I have clients that use shared hosting environments, or who have managed dedicated servers at big ISPs. The ISP won't update the PHP version of one server, because they tested the environment they installed on hundreds or thousands of machines, and they're guaranteeing service availability and security of their machines (that's what the clients pay for, after all). But I can easily bundle Creole, Propel etc with my web app (actually, I never rely on PEAR packages on the target machine and override the include path in my applications because I'm bundling lib versions for which I can guarantee functionality and compatibility). Minor PHP releases bring security fixes, bug fixes and VERY minor feature enhancements only, anyway. Is_subclass_of() was one of the few feature improvements back then. I realize it's nicer, and it will save seven lines of code. But we don't sacrifice ANYTHING by enabling 5.0.* compatibility here. Neither speed (usually one call only, the for-loop doesn't matter at all) nor anything feature-wise.
- David > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mike Vincent > Sent: Friday, July 22, 2005 4:59 PM > To: Agavi Development > Subject: [agavi-dev] Call for Votes: Expected Version Baselines > > This topic has risen from the discussions of singleton model > implementation and I think deserves clarification. The argument is > what versions of php should we expect to be installed. > > (A) 5.0.0 - We should target php as it was released at version 5.0.0. > - Conditional checks would need to be added for any features or > changes in behavior to php which were added after the 5.0.0 release > that are to be utilized in the framework. To take the specific case > that spurred the discussion http://php.net/is_subclass_of supports > checking if a class is a subclass of a parent as of 5.0.3 where as > prior versions of the function only supported checking against a live > object. In order to utlize this change in behavior, we would need to > check if the current php version is equal or greater to 5.0.3 and if > not provide a workaround. > > (B) We should target the most current stable version of php, 5.0.4 at > this time and expect developers will be running a current release of > php. > > I dont think it is in the scope of the framework to pander to admins > that dont practice good package adminstration by keeping their > packages up to date and so I firmly believe (B) to be the best > practice we should be following. If we do not target the latest stable > release of the applications we intend to collaborate with, we need to > generate a policy to determine what factors will affect the target > platform(s). I believe the outcome of this vote should be extended to > not only php but any other application we intend to be used, ie: > Phing, Propel, SimpleTest, PhpUnit2, Creole, MySQL, et al. > > > So come one, come all, throw your 2cents in so we can establish the > baseline. > > -Mike > +1 B > _______________________________________________ > agavi-dev mailing list > [email protected] > http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
