#39372 [Sus->Bgs]: Incompatibility in the PHP API.

ID: 39372 Updated by: jani@php.net Reported By: cm at cmunt dot demon dot co dot uk -Status: Suspended +Status: Bogus Bug Type: Compile Failure Operating System: All PHP Version: 5.2.0 New Comment: Abstract issues in release processes are not bugs. Use the mailing list to discuss such issues. Previous Comments: ------------------------------------------------------------------------ [2006-11-04 10:35:32] rasmus@php.net We take these breaks extremely seriously and go out of our way to not break BC. We never break BC in a sub-release (the z part of x.y.z) and if you look at the frequency of the other releases you will find that there is actually quite a while between BC breaks. Of course, if you download intermediate versions from CVS during development, you will be hit more often. But the actual recent bumps have been: For the 4.x branch: 4.3.0 Dec.27, 2002 4.4.0 Jul 11, 2005 In the 4.3 to 4.4 case, the change was minor, but necessary. Most extensions weren't actually affected, but it was still a change, and we didn't want to hide it. For the 5.x branch: 5.0.0 Jul 13, 2004 5.1.0 Nov 24, 2005 5.2.0 Nov 2, 2006 Each of these have also been quite necessary in order to improve a number of areas in the API. It's nice to say this can be solved by API abstraction, but that means getting the API perfect up front. ------------------------------------------------------------------------ [2006-11-04 09:49:59] cm at cmunt dot demon dot co dot uk Description: ------------ You will probably not regard this issue as bug and it is something that you are no doubt already aware of but it is a problem that, in our experience, causes no end of confusion and frustration among many users of PHP. The issue is this: pretty much every new release of PHP (including a significant number of minor upgrades) requires that all third party extension modules be rebuilt from source. There doesn’t appear to be any technical reason why this should be the case – after all, I’ve yet to see a situation where module code has to be changed on upgrade. This is a huge nuisance – particularly since many PHP systems these days are either pre-installed in binary form or tend to be distributed as pre-built kits (e.g. Windows). The requirement to rebuild could be removed by abstracting the data structures used in the PHP API to a higher level – in much the same was as Microsoft has done with ISAPI extensions to IIS. Incidentally, I seem to remember the PHP community being up in arms in the early days of Apache v2 when every minor upgrade (2.0.x) required third party Apache modules to be rebuilt – i.e. the PHP DSO. In the end the Apache Group capitulated and properly abstracted the API such that a rebuild would only be necessary between _major_ upgrades. This brings me to another problem with PHP: there seems to be no way of telling in advance whether or not third party modules will need rebuilding. Sometimes a minor upgrade will require a module rebuild; sometimes not. A little more effort and/or rationalization in this area would be much appreciated ! ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=39372&edit=1