On Wed, 2002-01-02 at 17:09, Joao Prado Maia wrote: > > On Wed, 2 Jan 2002, Zeev Suraski wrote: > > > At 16:06 02/01/2002, Björn Schotte wrote: > > >* Zeev Suraski wrote: > > > > Well, I think that the main motivation for separating the modules away was > > > > the release schedule. I.e., separating the release schedule of each > > > > extension from the release schedule of the PHP core itself. > > > > > >Jep. Just to note: I'm +1 for it. > > > > I'm +1 for separating the less popular ones, but I'm -1 for separating > > everything (look up the archives as to why...) > > > > Why not separate everything and then bundle the more popular ones to the > normal PHP distribution on the time of a release ? I would love to be able > to upgrade just the 'GD' extension if there was a bug on the extension on > release PHP4.1.12 and it was fixed on PECL version of the extension > 2.1.23. > > I would also love to be able to tell the users of my application to just > use the PEAR installer to download and install the bugfix release of the > GD extension instead of telling them to not use a particular buggy / not > compatible version of PHP. > > I can understand that it will mean more work to you guys to handle > several release independent extensions, but if you can just use the PEAR > installer to download the stuff from the repository, you will be able to > download the stable releases from PEAR and then build the general PHP > distribution.
I'm getting into this discussion three weeks late, but anyway... There is _one_ issue that needs to be dealt with seriously and solved if this is all going to work: binary compatibility for loadable extensions. If you upgrade PHP to a version where Zend got some tiny new function (that your extension does not use), you still need to rebuild your extension. This is a problem, rebuilding PHP and a gazillion extensions separately is a lot more work than just rebuilding PHP with the same config.nice you used last time. I guess there are mainly two cases where ZEND_MODULE_API_NO changes: 1. A new function is added, does not affect old extensions, so they should be able to load. 2. A function's parameter list is changed, may affect old extensions. The best thing is of course to not change parameter lists, but if it's really needed we should try working out something. Libtool's versioning system should be able to help us out, but it would require going from dates to consecutive numbers (or adding the latter). - Stig -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
