> [...] > different distribution packages can be > built when php releases occure, such as 'php core' which would contain > the 'most important' stable extensions, 'php stable' which would contain > all stable extensions, and 'php bleeding' which could be a package with > the latest development snapshot at time of release. > > With this also extensions now can take on a life of their own, releasing > at different times than php, and visaverse. I think this would make > releasing new versions of php much more manageable.
>From my past experiance, Ive found this sort of idea to be great - if the modules are retrieved else where, otherwise you end up with a support nightmare. Currently in the bug tracker we only need to ask what version of PHP they have and we automatically know what version all the of the modules are as they come bundled. If all the modules are updateable independantly of the PHP release having "PHP x.x.x" installed is no longer enough release information, we (via the end user) would also have to gather the version number for each module - ouch. Not to mention the painful testing! [eg:] I have 4 installations running 4 different versions of PHP for regression testing and bug fixing. If I relied on 3 different modules and wanted to check 2 versions of each, I would need 4 * 3 * 2 (24) installations - just to test. Im not against the concept of modules, but Id encourage the idea to be well thought out (especially the impact) as well as encouraging them to be thought more of "plug-ins" which are independant and may well be "upgraded". </concerned> -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software & Systems Engineer First Creative -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
