Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
[...] 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
RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)
I tend to agree that completely separating PHP from the modules does cause a problem when it comes to support modules, etc. However, IMHO I feel that as the numbers of modules written for PHP increases there becomes a greater and greater need to separate modules from the core of PHP. When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module. Also, on that note, is there any hard and fast standard in place for modules/extensions and the minnimum PHP version those modules support? I.e. is there anything that is designed to prevent me from trying to load a module in PHP 4.0 when it won't work with any version of PHP less than 4.2? I mean more than it throwing an error at compile-time of course. When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file: module name=gd Allow_jpeg=true Allow_tiff=false /module These are all just thoughts I have.. Feedback is more than welcome. I think a system such as this would accomplish a number of (in my mind) benfitial things: 1) Faster and easier installations of PHP By removing all of those compile-time ./configure options it will make PHP much easier to compile and install. Problems with a single module at compile-time won't stop a user from getting PHP running, and if there is a problem when the module is dynamically loaded it will be easier to figure out what's going wrong. 2) More accurate and managable module maintaing If modules are completely separated from PHP itself, then the status of a particular module, the people who are maintaining it, news about the modules, etc. will be easily found. There are more, but it's late and I'm going to get to sleep :) Like I said, feedback is more than welcome and I'd love to work with whomever is interested to move PHP in this direction. Cheers, John -Original Message- From: Dan Hardiker [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 3:59 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PHP in 2003 (leading to PHP 5) [...] 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit
RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)
[John Coggeshall] These are all just thoughts I have.. Feedback is more than welcome. I think a system such as this would accomplish a number of (in my mind) benfitial things: 1) Faster and easier installations of PHP [...] 2) More accurate and managable module maintaing [...] Also, having the php configuration (compile-time) separated from the module configuration (run-time) would enable external build structures (such as the FreeBSD ports system) to install base php installations, and with it tools to update/install/deinstall modules dynamically. For jack-in-the-box (preconfigured) systems/packages like RedHat rpm's / other binary distributions, this would also have the same advantage. [currently 3 or 4 binaries are created depending on the amount of modules you want and in what way you want them configured] -- 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
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
On Thursday, January 2, 2003, at 05:08 AM, John Coggeshall wrote: When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module. I tend not to see this as the real issue. The bug system can be adapted to our needs as we see fit. The bigger issue is the QA team time, energy, and effort that can be expended to all these test scenarios. This type of decision though will have to be made by the PHP/QA team, and not really by PHP-DEV. If this is of concern to you (developers), I suggest you (developers) become active in the QA process. I really don't see this being an issue any different for PHP Developers than currently setup. Which is support only exists for the latest PHP engine (hence the please try newer version bug responses popularity). When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file: module name=gd Allow_jpeg=true Allow_tiff=false /module Just remember the idea right now is to move things into PECL to get ready for an eventual version freedom from PHP, but that is not happening just yet. Stig Bakken has suggested this in the past, and you'll find it in archives, that this would be taking the first step towards, working out a lot of the bugs if found and getting the process to iron out. Please realize this change also removes the PHP idea of anyone can fix/add/modify to an extension mantra, and forces it to a realm of per extension release manager/authority. While I like this idea (something I and few others have advocated for awhile), it takes a rather 94 degree turn from how PHP has been developed for the last few years. But it also removes the need to worry about what is enabled by default :) 1) Faster and easier installations of PHP By removing all of those compile-time ./configure options it will make PHP much easier to compile and install. Problems with a single module at compile-time won't stop a user from getting PHP running, and if there is a problem when the module is dynamically loaded it will be easier to figure out what's going wrong. This isn't necessarily the right track to take. Remember that Windows users do not have the need/use of a compiler on their local machines always. As such, a system for distributing a binary is required. This has been hashed out, and Stephen Esser was at one time working on implementing it. Please see the archives for more information about this. --- Dan KalowskyThought I'd visit the club, http://www.deadmime.org/~dankGot as far as the door. [EMAIL PROTECTED] - Don't Get Around Much Anymore, [EMAIL PROTECTED]Ella Fitzgerald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP in 2003 (leading to PHP 5)
I hope you all had a joyous night last night and that it forms that start of a great New Year! Now, let's get our heads straight on what we are doing for 2003 :) You may remember (especially if you read Derick's Look Back) that I said something about building against ZE2 by default once we released PHP 4.3 [1]. I still think this is a good idea because it will force us to make sure that things are working properly - those extensions that implement classes and manipulate objects need the most attention. Once we have stabilized the combination of 4.4 + ZE2, are there any other *realistic* goals for PHP 5 to fit into slot no. 4 below? Are there any reasons not to switch to ZE2 right away? --Wez. Roadmap: 1. Switch to ZE2 by default 2. Establish PECL CA authority and binary package/release process (particularly important for win32) 3. Bundle PHP-Soap (and stop the bleeding of PHP users) 3a. Collect underpants 4. ? 5. Profit [1] http://news.php.net/article.php?group=php.devarticle=87097 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
3. Bundle PHP-Soap (and stop the bleeding of PHP users) I know I've been saying for a while now that I'm going to start working on this again but I have yet to do it. I do plan to work on this again. I would like to see it bundled with php5 but it defintly needs some work. If its possible I would like to get a general timeline for a cycle of php5 so I can know if I can get it to a release level before then or if I need help. I know there are other issues with it too... like bundling libxml2 but they can all be worked out. as you can notice I stripped out all the rest of the email ;) - Brad __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
Roadmap: 1. Switch to ZE2 by default 2. Establish PECL CA authority and binary package/release process (particularly important for win32) 3. Bundle PHP-Soap (and stop the bleeding of PHP users) 3a. Collect underpants 4. ? 5. Profit #3 doesn't belong in a general roadmap. What does fit in, that also covers #3, is having all extensions moved out to pecl, and a build/release system that can build distribution packages based on the last stable release of extensions in pecl. With that (for example only), 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. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
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. Do you? Not every extension has a named maintainer .. Shane - Steph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
I think this would make releasing new versions of php much more manageable. Do you? Not every extension has a named maintainer .. At worst, the maintenance would be as it is now. Or is the worry that some extensions will go unmaintained if they are moved into PECL? My take on that would be that any extension that would die if it was moved out of core should be moved out of core for just that reason. George -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
I think this would make releasing new versions of php much more manageable. Do you? Not every extension has a named maintainer .. At worst, the maintenance would be as it is now. Or is the worry that some extensions will go unmaintained if they are moved into PECL? My take on that would be that any extension that would die if it was moved out of core should be moved out of core for just that reason. Fair comment, I just went through the list. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
