In a post to his site Fabian Schmengler has shown how to use class_alias to prevent breakage while renaming or moving classes around in your application during refactoring.

Sometimes you want to rename a class or move it to a different namespace. But as soon as it is used anywhere outside the package, this is breaking backwards compatibility and should not be done lightheartedly.

Luckily there is a way in PHP to have both, the old class and the new class, while deprecating the old one: class_alias().

He then gets into the details of using this handy function to define the links between the files, necessary in two different places to prevent autoloading breakage. He also offers an alternative, making use of the "autoload.files" option in the Composer configuration (but this means adding each one to that list). He finishes the post by suggesting one more thing as you update your code: making it with an @deprecated annotation to help locate it later (and flag it in your IDE of choice).

Paul Jones has an interesting post to his site that makes the link between software versioning and public interfaces your code provides. He points out that, despite semantic versioning helping to define how to version your code, there's still some ambiguity about it and backwards compatibility.

Adherence to Semantic Versioning is just The Right Thing To Do, but it turns out you have to be extra-careful when modifying public interfaces to maintain backwards compatibility. This is obvious on reflection, but I never thought about it beforehand. Thanks to Hari KT for pointing it out. Why do you have to be extra-careful with interfaces and SemVer? [...] If we remove a public method, that’s clearly a BC break. If we add a non-optional parameter to an existing public method, that’s also clearly a BC break. [...] However, if we add a new public method to the concrete class, that is not a BC break. Likewise, changing the signature of an existing method to add an optional parameter is not a BC break either. [...] But what happens with an interface?

He suggests that changing current functionality (such as adding a non-optional parameter) is a backwards compatibility break but in an interface so is adding a new method. By adding a method you "break" the implementation someone already has, causing plenty of trouble for the users. He wonders about the right approach for making these updates, if it's creating a new interface or just extending the current one and having users migrate. He also includes a few update notes about abstract classes and how Symfony handles BC breaks too.

Davey Shafik has a recent post to his blog about what he calls "The Blowfish Debacle" - the issues that came up with the PHP 5.3.7 release to upgrade the crypt_blowfish version that resulted in a larger error being introduced.

This was a great security fix, solving an issue with insecure passwords due to incorrect behavior. HOWEVER, what wasn’t made clear, is that this change was actually a backwards compatibility break. If you upgraded to 5.3.7+ data hashed pre-5.3.7 would no longer match data hashed post-5.3.7; this means if you use it for passwords, it will no longer match. So what’s the deal here?

He talks about the differences in the two methods of encryption, the newer being the "more correct" way of doing things. If you need the backwards compatibility because of previously hashed values, you can use the "$2x$" prefix instead of the usual "$2a$". He includes a snippet of code that can be used to upgrade all of your previously hashed blowfish passwords up to the new format.

On McGlockenshire.com there's a recent post looking at some of the features of the upcoming PHP 5.4 release and how they'll be glad to get rid of the "prehistoric cruft" that's accumulated around the language over the years.

It’s incredibly rare for the Internals crew to ever consider breaking backwards compatibility, but some of the most important changes in PHP 5.4 do just that by removing old "features." None of these changes should impact modern PHP code. If somehow you get bitten by any of these changes, chances are that your code dates from the PHP 4 era.

Included in his list of updates/removals/improvements are things like the full removal of safe_mode, dropping register_globals, pulling out call time pass by reference and the removal of the session registration methods.