Full disclosure: I’m not on the internals team. The topic of this blog post just happens to push my buttons and I want to be able to point people to a URL rather than answer the question over and over again.
A question that seems to be popping up more and more these days is, "When will PHP 6 be released?" It’s especially annoying because the people that
enjoy an exercise in futility ask this question are the same people that simply refuse to take WIR for an answer. Or maybe they just read into the hype generated by trigger-happy publishers who want to preempt a stable release, I don’t really know.
There’s been no alpha or beta release of 6; it hasn’t moved anywhere outside of the CVS repository yet. I would think that would provide some indication that 6 is still a ways off. The feature freeze for 5.3 was originally set for 7/24/08. The first beta release only came out this week. This is all public knowledge and I think a pretty good indicator of the speed at which the landscape is changing.
Given what was originally planned for 6 and how much of it ended up in 5.3, the 6 envisioned today could be worlds away from what actually ends up being released. Take a look at those TODO lists; the amount of work left to be done is anything but trivial. The internals team is not a corporate entity and its members are not compensated for their work in any way. They are volunteers and most work on PHP when they’re off the clock from their day jobs. This limits how quickly progress can be made and how accurate estimated release dates can be. So respect them and their time and stop asking when it’s going to be ready, because they don’t really know much better than you do.
Another thing: PHP is server-side software. It’s not a new web browser coming out where the user may or may not upgrade when you have had time to adapt your application to work with both the old and new versions. No one is forcing you to upgrade the installation you use internally. If you have customers that maintain their own PHP installations, don’t feel pressured to be on the bleeding edge just because they want to be.
Be sensible: don’t lag more than two or so minor point versions behind the current stable offering, don’t immediately upgrade to a brand new stable version, and have automated tests that can be run against release candidates so it’s easier to discern issues that might arise when a stable release does come out and you want to upgrade.
If you really want to be prepared, there are several things you can do. Keep tabs on the accepted and implemented RFCs to see what features are being added and what effect, if any, they have on BC. Search the bug tracker for issues reported and fixed in the branch relevant to you. Don’t limit yourself to testing new versions with your own test suites, but help to write tests for PHP itself to ensure that new versions are as stable as possible. These will make your time much better spent than asking a question that has no definitive answer. And it will keep the rest of our blood pressures all the lower for it.