Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

The PHP development team would like to announce the immediate availability of PHP 5.4.5 and PHP 5.3.15. This release fixes over 30 bugs and includes a fix for a security related overflow issue in the stream implementation. All users of PHP are encouraged to upgrade to PHP 5.4.5 or PHP 5.3.15. For source downloads of PHP 5.4.5 and PHP 5.3.15 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. The list of changes are recorded in the ChangeLog.

Fixes include updates related to problems in the FPM, Iconv, JSON, libxml, Phar and Zip extensions. You can find the links to these and other bugs in the Changelog.

The PHP development team would like to announce the immediate availability of PHP 5.4.4 and PHP 5.3.14. All users of PHP are encouraged to upgrade to PHP 5.4.4 or PHP 5.3.14. The release fixes multiple security issues: A weakness in the DES implementation of crypt and a heap overflow issue in the phar extension. PHP 5.4.4 and PHP 5.3.14 fixes over 30 bugs. Please note that the use of php://fd streams is now restricted to the CLI SAPI.

As always, you can download this latest release from either the downloads page (source) or from the Windows site (binaries). See the Changelog for the full list of updates.

No one has told me this and I don't need them too. I feel like one bug that has a negative impact on the user experience is too many bugs. I've been programming for over 5 years professionally and I still introduce bugs into my code. [...] I don't like the expectation that I (and maybe others have) that my code must be perfect when I am not perfect. I don't like the fact that it only takes one mistake to affect so many people. [...] I'm wondering if others on here have every felt this way. What have you done about it?

Suggestions in the comments talk about everything from dealing with the apparent burnout the developer is facing, a reminder that no code is bug free and some recommendations of testing and bug tracking to help make the quality of the code better (and give visibility into the level of work being done).

Roughly a month ago I posted the first in, what should become, a series of development updates concerning Phing. This second blog post details the most important updates during the past four weeks as Phing is moving steadily towards another release (2.4.10 is due out next week).

Updates mentioned in this post are:

• User Guide starts move to DocBook format
• Liquibase docs
• PhpDocumentor
• PHP 5.4 compatibility
• PHAR package
• Various (bug)fixes, the 2.4.10 release (listed)

Check out the full post for more details on each of these topics.

At the PHP UK Conference Rasmus mentioned that he wants more people contributing to PHP. There are plenty of ways how you can do that.

Derick points out two more immediate ways you can help, one not even requiring any C knowledge:

• Help test the Release Candidates (like the current PHP 5.4.0 RC8) with a call to "make test" just after your compile.
• The recently added "random PHP bug" functionality that's been added to the bugs.php.net site

From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

Troels Knak-Nielsen, father of pearhub, wrote to the pear-dev mailing list: "Unfortunately I have absolutely no time at hand for this project and probably won't for a foreseeable time. I still think it fills a need, so I'd be happy to hand over the keys to anyone who will take it upon them to move the project forward. I'll try to assist as best as I can, but probably won't have much time to spare. But the project is fairly simple anyway, so it should be relatively easy to get the main idea."

If you're interested in hosting or helping out with the project, let Troels know. Pearhub lets any project with a publicly facing repository be installed via a PEAR channel quickly and easily. For more information, see the project's FAQ.

The goal of this blog post is to number one serve me as a todo list of stuff that I personally think needs to be fixed before Symfony2 can be released. Hopefully it will also entice some people to help out with these tasks. I am focusing on the medium to large tasks. There are of course still a fair number of smaller fixes that need to be applied.

Items on the list include:

• switch Security/Validation components to using message key's rather than full sentences
• Assetic documentation
• Adding a DIC aware Serializer
• Better support for SSL'ed urls and assets
• ttempt to automatically determine service scopes

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 [When it's ready] 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.

He points out some of the current stats - PHP 5.3's beta release date as coming to the original date, that PHP 6 code hasn't even been moved outside of CVS and the amount of work left to be done on it before its even close to being ready. This is where you come in - the internals folks contribute their time (off-hours usually) to developing the language and can only do so much:

So respect them and their time and stop asking when it's going to be ready, because they don't really know much better [about PHP6] than you do.

He also suggests two other things that you can do to keep up with the current state of development - keep your version updated and track the RFCs to see what features are being added and any bugs that might still be open for pre-release. You have to be proactive about keeping up with the current status - otherwise, you have no room to ask, over and over, "when will it be done?"