⇥ Gentlemen, start your whining
As you probably know, PHP 4 is officially headed the way of the dodo.
From a strategic perspective, letting go of PHP 4 is the right thing to do—it is, indeed, long overdue. Many others have pointed out a number of reasons why this is the case; for my part, I simply note that I have always thought of PHP 4 as an incomplete work of art—it certainly does its job, but it does it with, in some case, a high degree of awkwardness. The structural changes that are part of PHP 5 make implementing complex functionality much easier—which is partly the reason why some of the “cool” new features haven’t been backported (and I am not talking about OOP).
At the same time, I can’t help but think that the decision to officially deprecate the 4.x branch is going to cause nothing but whining—because those of us who have already decided to move to 5.x will not be affected by it in any way, and those have decided to stick with the older version are now faced with a task that, in some cases, is going to feel impossible—porting hundreds of thousands of lines of code from 4.x to 5.x.
Already a few broken fans have started grinding and, as you can see from the comments on that blog entry, they have plenty of company to get along with. There is an argument to be made that these people simply have no idea what they are talking about, because they just don’t understand what “end of life” really means in the contest of an open-source project like PHP.
Given enough openness and usage, development platforms never really die. When they usually do, it’s either out of scarcity of usage or a force upgrade path imposed by a commercial vendor that can control its market. Where the market itself has significant influence over the life of the product, it’s the market that decides whether a platform lives on or not. That’s why, for example, Microsoft can essentially obliterate ASP out of existence in favour of .Net, but IBM can’t dislodge its medium- and large-size customers out of their reliance on languages like Cobol or RPG.
The fact that most IBM minis still do most of their work in RPG, however, does not mean that other development environment do not become available to them. For example, IBM has been pushing Java and PHP on its iSeries platform for a number of years now—but I don’t think that anyone has in mind that either of them will replace the twenty-year-old RPG applications for a long time to come.
Thus, I think that many of the core developers of PHP look at the 4.x end-of-life announcement not as a death sentence for PHP 4, but rather, in a more literal way, as an opportunity to simply state that the development of PHP 4 has run its course and that it no longer makes any sense to keep that branch open because it’s unlikely that any significant new features will be added to it. I can’t speak for anyone else, of course, but I seriously doubt that any of the core developers care at all whether anyone is running their site on PHP 3, 4, 5 or 6, and they are certainly not here to take their favourite environment away from anyone.
Consider it a “reaching maturity” announcement, if it makes you feel better—and consider that the “nobody really needs PHP 5”-style arguments never really hold any water, just like throwing percentages around is completely useless. Progress for the sake of progress is sometimes necessary for us to discover new, and sometimes better, ways of doing things. The fact that a vast majority of people still uses PHP 4.x means absolutely nothing: they will barely be affected by this decision anyway, since their platform has hardly changed over the last few years.
There is, of course, the fact that, according to the php.net announcement, no more security fixes will be applied to the 4.x branch after August 8, 2008, which, in my opinion, was a huge mistake. First, it is essentially an open invitation for all hackers to hold announcing any security flaws they discover until after 8/8/08. Second, there really is no good reason why security flaws cannot be fixed on an ongoing basis: since security fixes are usually the result of some external report, it should be possible to simply fix them as they come up. On the plus side, there is more than a year for this decision to be reversed, or for another team of folks interested in keeping PHP 4 alive to step in and fill the void.
Meanwhile, you can whine or you can think and contribute useful opinions. The choice is yours.