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.

A new project has been launched in the Laravel community to try to maintain some of the core Laravel components that have been deprecated by the framework - the Laravel Collective.

The Laravel Collective is a new Laravel community organization headed by Adam Engebretson and Tom Shafer. It’s primary goal is to help maintain the core Laravel components that have been deprecated by the framework. Currently the packages the Collective is taking over is HTML/Form and Annotations. They have a new site in the works which, when launched, will have complete documentation, team information, and more information on the packages. Until it’s launched you can check out their GitHub repository.

The full project hasn't launched yet, but if you're interested in becoming a part of it, you can sign up for their newsletter and get updates as they're posted.

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.

On the NetTuts.com site there's a new article posted talking about some of the new stuff that comes bundled in PHP 5.6 (the first stable version of which was released at the end of August 2014).

It's been a long time coming, but we finally have a new version of PHP. With it comes a some nice, new features, improvements to existing features, as well as features that have been removed or marked as deprecated. Let's dive in and take a look at everything that's offered by the latest version.

There's several items on the list, broken up into various sections, each with brief explanations:

• Backward Incompatible Changes (ex: json_decode, mcrypt)
• New Features (including constant scalar expressions, argument unpacking, phpdbg)
• Deprecated Features (call to static from non-static context, removal of HTTP_RAW_POST_DATA)

They also link to the list of all of the changed and new functions updated in the PHP 5.6.0 release and moving forward.

In a quick post to her blog Lorna Mitchell mentions a deprecated method in pecl_http that could cause problems for you down the road - addRawPostData.

I'm a big fan of pecl_http, which I use quite often as I work so regularly with APIs and on systems where I can get it installed, it's much nicer than PHP's curl extension. Recently though I've been often seeing output which reads: Function HttpRequest::addRawPostData() is deprecated

The alternative is to use the "setBody()" method on the HttpRequest object instead. This, in effect, does the same thing and sets the contents of the message to the raw data you'd like to post. Unfortunately, the PHP manual page doesn't reflect that this method is deprecated. You can find out more about the functionality the "pecl_http" extension has to offer here. It's a very flexible and reliable way for your scripts to interact with remote servers via HTTP calls.

New from the BiGiTSS blog there's a reminder for those looking to upgrade to the latest PHP 5.3 release - is your code ready?

If you are planning to upgrade to PHP 5.3 from PHP 5.2.x then you must think twice before you really do it. There are few things you should take care of. Recently last week I tried upgrading one of the web-server to PHP 5.3 from PHP 5.2.9 and it was not a good idea which I came to know later on.

They mentions all of the warnings/errors they found on the upgrade and spotted an issue with one of their external libraries that caused them to have to roll back that as well. Be sure to check the deprecated list before you try moving up your PHP version and ensure that things like the __toString override don't catch you and your application off guard.

On the SaniSoft blog today, Tarique Sani has a quick hack for CakePHP users needing to transition over from the deprecated vendor() call - import().

Use of vendor() function to load third party libs in CakePHP has been deprecated for some time now... It has been replaced with the more generic App::import() the usage is simple.

There's also a little trick you'll need to know for files with underscores (drop it and replace with an uppercase) and how to get it to be a bit more flexible and recognize vendor files in subdirectories or ones differently named.

Derick Rethans has pointed out a "gotcha" that was passed along to him (somewhat incorrectly) about the "name" attribute being deprecated in XHTML 1.0.

Just now somebody on IRC was claiming that the "name" attribute in HTML - the one that is used to give form input fields a name to be used in $_GET and _$POST in PHP is in fact deprecated. [...] But if you read correctly, it's only for the elements: a, applet, form, frame, iframe, img, and map.

For the official information, check out the section of the new spec dealing with this transition.

Derick Rethans has pointed out a "gotcha" that was passed along to him (somewhat incorrectly) about the "name" attribute being deprecated in XHTML 1.0.

Just now somebody on IRC was claiming that the "name" attribute in HTML - the one that is used to give form input fields a name to be used in $_GET and _$POST in PHP is in fact deprecated. [...] But if you read correctly, it's only for the elements: a, applet, form, frame, iframe, img, and map.

For the official information, check out the section of the new spec dealing with this transition.

In response to several other posts lately about the PEAR::DB package in PEAR (and things that could be done to improve it), David Coallier got a bit fed up and shared his opinion - "PEAR::DB is deprecated, got it?"

All new features are made into MDB2 and not DB, the only thing that is being done on DB is security fixes. So MDB2 is first of all, faster, smaller (Because of it's driver and modularity), easier, and has more features (LOB handling, Iterator, etc) and better end-user documentation, quite solid docs indeed.

Of course, the comments of the post are full of people arguing to keep it around and others that agree with David, especially in light of a MDB2 driver for the Zend Framework he mentions.