TJ Miller has written up a post for his site sharing a method he's created to verify the compatibility of a package in Laravel based on the version of Laravel installed.

I’ve been working with Honeybadger to build a new set of PHP integrations. I would like to write more about that soon, however, I feel like I’ve stumbled across something that could be useful to others. I wanted to share it as soon as I could.

For the Laravel package, I was aiming for Laravel 5.5 and newer support as it is the latest LTS version. [...] In hindsight, I don’t think that I actually ever tested it against a 5.5 install. I relied on the CI process to make those verifications for me.

[...] As Laravel 5.7 is now out, I needed to add support to both the package’s composer configuration and verification in CI. [...] Now that I am supporting three versions I felt that I needed a more specific way of verifying compatibility with different versions of Laravel.

He shares his initial version of his Travis-CI configuration, running tests on PHP 7.1 and 7.2 with the prefer-lowest flag. In order to make it easier, he updated this based on what he'd seen in other packages: adding a matrix that runs PHP 7.1 through 7.3 against versions 5.5.x, 5.6.x and 5.7.x to ensure compatibility across all variations. His resulting build looks something like this.

With each new major version of the PHP language comes a long list of changes. Along with these changes can come breakage with software that's not a direct part of the PHP core (or extensions). In this post to his site Remi Collet lists out a large number of the more popular PHP extensions and, along with the specific version numbers, breaks down which will work and which won't.

He actually has three lists: "compatible", "work in progress" and "not compatible for now". Fortunately, the "compatible" list is the longest and includes:

• geoip
• ip2location
• redis
• sphinx
• zookeeper
• varnish

There's also a pretty sizable list for the "work in progress" category, most of which are already in the "fixed upstream" category or have pull requests waiting for review to fix issues that were found. Most of the items in the "not compatible" list are either projects that are out of date or have moved away from the PECL extension approach to something more based in user-land code.

The SitePoint PHP blog has a quick tutorial posted helping you get your application PHP 7 ready with the help of the PhpCompatibility "sniffs" for the widely used PHP_CodeSniffer tool.

Sooner or later, there will come a time when you will need to migrate your projects to different PHP versions. How will you check if you’re compatible with a PHP version different to the one you’ve been developing on?

One possibility is always to install the version of PHP we want to migrate to, run php -l or something like PHPSA to check for syntax errors, check the PHP documentation for known issues with the migration and hope for the best. Or, we can use some available third party tools to check for PHP version compatibility in our projects.

The article then introduces the PHPCompatibility set of sniffs for PHP_CodeSniffer and installing them with a "git clone" in the right Standards directory. Also included are some basics for using PHP_CodeSniffer (like the command line options) and an example of some of the output from the compatibility check. The post wraps up with a real-life example using the PHPMailer codebase and testing it for PHP 5.6 readiness.

The Toptal blog has a new post talking about PHP 7 including some of the new things it includes (and what's gone from previous versions of the language).

One of the most exciting events in 2015 in the PHP world was the release of PHP 7, 10 years on from the release of the last major version, PHP 5. With a major step forward, PHP 7 introduces plenty of new features and performance upgrades. [...] This guide should serve as a quick tour on what to expect if you plan on moving your existing applications, or building new ones, on top of PHP 7.

He starts with a topic quite a few people wondered about - "where did PHP 6 go?". Following this he gets into some of the performance boosts that PHP 7 brings with it and updates to the "syntactic sugar" it offers developers to make their lives easier. He then gets in to the new features in this version like:

• Scalar Parameter Types & Return Type Hints
• Engine Exceptions
• Anonymous Classes
• CSPRNG Functions
• Unicode Codepoint Escape Syntax

He finishes off the article looking at the migration from PHP 5 to PHP 7 and highlights some of the potential compatibility issues that could pop up during the migration.

On the HHVM blog (Facebook's HipHop Virtual Machine project) they've posted about support for PHP 7 features that they've been working into HHVM and Hack to support backwards compatibility with this latest major version of the PHP language.

For those that haven’t been following along, the next version of the PHP language, version 7.0.0, was very recently released. Those of us working on HHVM offer our congratulations to all the contributors to this latest release! We’re all really excited to see this release come out the door, and for what it means for the future of PHP.

The release has implications for HHVM as well. [...] The HHVM project is committed to continuing to support the evolving PHP language, and as such we are proud to announce that the current nightly releases have support for all major PHP 7 features, and the upcoming 3.11.0 stable release will be the first release of HHVM with support for the major PHP 7 features.

There are some backwards compatibility issues that PHP 7 introduced but the HHVM project has opted to support both the PHP 5 and 7 users simultaneously. This is made as low friction as possible either through silent compatibility or though a hhvm.php7.all ini configuration setting.

As was announced on both the PEAR blog and Christian Weiske's blog, the PEAR project has made a major update to add PHP7 support preparing it for the upcoming major release.

The new PEAR installer release adds PHP 7 support while dropping support for PHP 4 - 5.3. It also fixes a nasty SSL issue that made it hard to use on PHP 5.6. With the update, strict warnings about static calls to a non-static PEAR::isError() are a thing of the past.

I've just published the first preview version: PEAR 1.10.0dev1.

Upgrading your version of the PEAR installer is as simple as a call to pear upgrade specifying this dev1 release (command is included in the post). He also links to some pre-release versions of the go-pear and pear-nozlib installers.

On the Symfony blog they've posted an announcement that they've achieved 100% compatibility with HHVM, the virtual machine/engine created by Facebook, in version 2.3 of the framework.

HHVM is an open-source virtual machine designed for executing programs written in Hack and PHP. HHVM uses a just-in-time (JIT) compilation approach to achieve superior performance for PHP applications. During these last past months, HHVM and the upcoming PHP 7 version have engaged in an epic battle to become the fastest PHP engine. At Symfony we are thrilled because this fierce competition will ultimately benefit all of us.

The post shows some of the commits that were made towards the effort including the first from Joseph Bielawski and the final push from Nicolas Grekas in pull request 15,146 correcting issues in the Debug, DependencyInjection, Filesystem, Form, HttpFoundation, Process and Routing components.

According to a wiki announcement made on the PHPUnint GitHib repository, the next major version of the popular unit testing tool will only support PHP 5.6 and above.

According to our release process, PHPUnit must be compatible with all versions of PHP that are actively supported by the PHP project.

Active support for PHP 5.4 ended on September 14, 2014 and active support for PHP 5.5 will end on June 20, 2015. The active support for PHP 5.3 already ended on July 11, 2013. By the time PHPUnit 4.8 will be released, the only actively supported version of PHP will be PHP 5.6. The next version after PHPUnit 4.8 will not support PHP 5.3, PHP 5.4, and PHP 5.5 anymore. As PHPUnit follows Semantic Versioning the major version number must be incremented when the minimum required version of PHP is increased.

This will be a major change for many projects out there used to just fetching the latest version of PHPUnit for their projects. With PHP 5.3 and 5.4 making up such a major part of the currently installed versions, this could really help to push those hosts/companies using these unsupported versions for upgrades. It's good to see a prominent project like PHPUnit pushing the community to supported versions.

In this new post on thePHP.cc blog Stefan Priebsch talks about some of the backwards compatibility breaks that will be coming with PHP's next major version, PHP7.

According to the PHP project's current time line, PHP 7 is scheduled to be released later this year. The version number 6 will be skipped for good reasons. As is expected of a new major release, there will be some breaks in backwards compatibility. Such breaks are always a double-edged sword: some have been eagerly awaiting the removal of legacy features, others expect that existing software keeps working without modifications. The PHP project is notorious for keeping some sins of the past dating back to PHP 3 in an effort to ensure backwards compatibility. Now, with the release of PHP 7, the decision has been made to remove some features that have been marked as "deprecated" in PHP 5.

He talks about how PHP will be "re-engineered" for this major release including a uniform variable syntax and some of the things this could break (like Magento 1). He also mentions the removal of the mysql (not mysqli) extension and a major issue - that PEAR has stopped working in recent versions of PHP7 (built from the current codebase) because of how it calls non-static methods statically.

Tony Marston has posted a plea to the core developers of the PHP language when it comes to some of the changes happening with constructors in classes: "please do not break our language."

This post is addressed to PHP's core developers who are proposing to break our beloved language yet again in the next major version of PHP (version 7) by removing functionality which has worked perfectly for years simply because it does not fit in with their ideas of how it should be done today. I am talking about PHP RFC: Remove PHP 4 Constructors (and this post on php.internals) which proposes that all code with PHP 4 style constructors be made invalid in favour of the "correct" method which was introduced in PHP 5. This is despite the fact that both types of constructor have lived quite happily side by side for over a decade and that large volumes of code, including PEAR libraries, were written in the PHP 4 style.

He suggests that this kind of change would require quite a bit of code to be changed, causing headaches for a large audience out there using older PHP code. He then gets into some of his opinions and thoughts about who "owns" PHP - is it the core development team working on the language itself, the community that uses the language (or a combination of both)? He proposes two definitions of "improvement" in respect to the needs of developers using the language and core developers. He suggests that the core developers are changing the language "just because they can" and that breaking backwards compatibility with something like this is a big mistake.

He then shares some of the comments from the php.internals mailing list on the subject of the constructor change, both for and against. He also points out a few other places where backwards compatibility was broken and the resulting changes that had to be made by developers. He suggests a "if it ain't broke, don't fix it" kind of approach

If there is a choice between a lazy or incompetent core developer doing only half a job and leaving the 240 million members of the greater PHP community to clear up his mess, then it should be obvious to anyone who has more than two brain cells to rub together that it is the core developer who needs to put in the extra effort so that the greater PHP community does not have to.