In a new post to his site Colin O'Dell has shared a Composer "metapackage" that can help you avoid unsupported Symfony component versions with the help of Composer's own internal version checking system.

Using symfony/symfony makes Composer install all Symfony Components in the same version. But when using the standalone packages, Composer might install dependencies in a different major version - for example, symfony/validator v2.8 is compatible with symfony/translation v3.0.

This is fine if you don't want to stick strictly to Symfony LTS versions, but it does mean that you could end up using versions of components which no longer receive security updates.

Rather than having to specifically define (and manage) the versions of package you want to install, you could opt to install his package that will do the hard work for you. It uses the "conflict" handling in the Composer configuration to limit version numbers on many of the popular Symfony packages and requires them to be greater than or equal to certain versions.

The latest episode of the Laravel News podcast, hosted by Jacob Bennett and Michael Dyrynda, has posted their latest episode: Episode 43.

Jake and Michael return after a few weeks' hiatus to recap Laracon US 2017, the big reveal of Laravel Horizon, and catch up on the latest framework news.

You can read the full episode transcript which includes time markers and links.

The post also includes links to several of the topics and software mentioned in the episode. If you enjoy the show be sure to subscribe to their feed to get notifications when the latest episodes are released.

In a new post to his site Frank de Jonge makes a distinction between packages versus components, pointing out that components are always packages but packages are not always components, and what it really boils down to is a problem of dependency.

The PHP landscape has fully transitioned into its Package Age™ [...] However, due to PHP's nature, there are some problems. While packages are great for re-use outside of frameworks, dependencies are still an issue. Namespaces resolve conflicts between classnames, but they do not offer a solution to package versioning. Especially in a framework-context, this can become very problematic. A real-world-example for this is Guzzle.

In his Guzzle example he describes the main problem - when packages restructure or make changes incompatible with prior versions and dependencies conflict and both must be installed. He also points out that, while this is bad for just packages, it can be made even worse working with components (his name for framework-based packages). Problems he mentions are the previously mentioned dependency conflicts but also some unexpected quirks with how Composer chooses to install packages. He gives an example of this second one with the installation of the Symfony EventDispatcher component and how, upon closer inspection, Composer seems to be installing two versions of the library at once.

On The Nerdery's blog today there's a new post that shows you a way to help test your code for PHP 5.4 and 5.5 - via PHP_CodeSniffer - as well as mentioning some of the changes that came with these versions.

Do you want to know if your code is compatible with that latest version of PHP? Do you need to upgrade your existing PHP website to a newer version of PHP? Do you want to see if your legacy PHP code is using any features that have been removed or deprecated in later versions of PHP? [...] ou need to migrate your existing code to ensure nothing will break when the upgrade occurs. How can you accomplish that?

They start with the list of differences (and backward incompatible changes) in the newer versions and point to the migration pages for each. Then they get into the use of PHP_CodeSniffer and some additional rules provided by Win Godden for checking the compatibility. With these added in, you can call the "phpcs" checking tool with the "PHPCompatibility" standard and check out the results. An example of what you might see on an older application is included in the post.

Stuart Hebert of the Gentoo blog has posted this new item as a reminder to all of those naysayers out there that didn't think it could be done that PHP4 and PHP5 can live together happily on the same box.

As an illustration of its possiblity, he points to this article from Andreas Korthaus showing how it's done under various different types of installs (Apache/CGI, Aapche/suphp).

Stuart Hebert of the Gentoo blog has posted this new item as a reminder to all of those naysayers out there that didn't think it could be done that PHP4 and PHP5 can live together happily on the same box.

As an illustration of its possiblity, he points to this article from Andreas Korthaus showing how it's done under various different types of installs (Apache/CGI, Aapche/suphp).

Sebastian Bergmann has updated a previous benchmark concerning the performance of PHP 5.1 as built with various versions of GCC.

I updated my previous benchmark of PHP 5.1. This time around I built PHP with GCC 3.4.5, GCC 4.0.2, and GCC 4.1.0.

The bottom line result seems to be that GCC 4 generates slightly slower code:

• GCC 3.4.5: 15.223
• GCC 4.0.2: 17.896
• GCC 4.1.0: 17.847

The detailed results are also included, showing how he came to each point mentioned above. They include the specs for the machine, how the testing was set up, and the detailed breakdown of the stats for each GCC version.

Sebastian Bergmann has updated a previous benchmark concerning the performance of PHP 5.1 as built with various versions of GCC.

I updated my previous benchmark of PHP 5.1. This time around I built PHP with GCC 3.4.5, GCC 4.0.2, and GCC 4.1.0.

The bottom line result seems to be that GCC 4 generates slightly slower code:

• GCC 3.4.5: 15.223
• GCC 4.0.2: 17.896
• GCC 4.1.0: 17.847

The detailed results are also included, showing how he came to each point mentioned above. They include the specs for the machine, how the testing was set up, and the detailed breakdown of the stats for each GCC version.

In this new article from InternetNews.com, there's a look back at where PHP has come from as well as a look forward to the new year and what we can expect.

PHP has long been a favorite dynamic programming language for Web developers. After 10 years of growth, 2006 looks to be a banner year for the open source language as its collaboration framework, partner ecosystem and the language itself are expected to grow and gain new users.

Look for a confluence of three distinct branches of the PHP language, with versions 4, 5 and 6 all likely to be out in the market in 2006. It will also be a year in which PHP will continue to challenge .NET and Java as the online language of choice for developers.

They also look at a brief history of PHP, what PHP6 has in store for the community, the confusion that the "three versions" (PHP 4.x, 5, and the upcoming 6) can cause. They wrap it all up with a positive note about PHP and its future from Andi Gutmans of Zend.

In this new article from InternetNews.com, there's a look back at where PHP has come from as well as a look forward to the new year and what we can expect.

PHP has long been a favorite dynamic programming language for Web developers. After 10 years of growth, 2006 looks to be a banner year for the open source language as its collaboration framework, partner ecosystem and the language itself are expected to grow and gain new users.

Look for a confluence of three distinct branches of the PHP language, with versions 4, 5 and 6 all likely to be out in the market in 2006. It will also be a year in which PHP will continue to challenge .NET and Java as the online language of choice for developers.

They also look at a brief history of PHP, what PHP6 has in store for the community, the confusion that the "three versions" (PHP 4.x, 5, and the upcoming 6) can cause. They wrap it all up with a positive note about PHP and its future from Andi Gutmans of Zend.