php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39372 Incompatibility in the PHP API.
Submitted: 2006-11-04 09:49 UTC Modified: 2008-11-27 02:13 UTC
From: cm at cmunt dot demon dot co dot uk Assigned:
Status: Not a bug Package: Compile Failure
PHP Version: 5.2.0 OS: All
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: cm at cmunt dot demon dot co dot uk
New email:
PHP Version: OS:

 

 [2006-11-04 09:49 UTC] 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 !



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-04 10:35 UTC] 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.

 [2008-11-27 02:13 UTC] jani@php.net
Abstract issues in release processes are not bugs. Use the mailing 
list to discuss such issues.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 08:01:32 2024 UTC