When it comes to new versions of software, the same questions always come to mind. Is the update worth it? And much more important: Will everything still work after the update? Is it even possible to find an error quickly, and how easily can it be fixed afterwards? As if that wasn't enough, the question often arises as to which cascade of further updates and thus new, additional problems the supposedly quick update might cause. So why invest the effort and take the risk, when everything is working so well?
It is often very difficult to measure the business value of a software upgrade. So how do you convince the product owner? Sure, security is important, especially in times of the GDPR, and so time is usually grudgingly granted at least for the installation of necessary (security) updates. But where is the business value beyond that?
In order to answer these questions, one must first clarify what needs to be updated. If, for example, it is the latest version of the company's accounting software, it will be hard to avoid an update, if only because of the changed laws. But what about a programming language and its runtime environment? New language constructs and improved functionalities may be pleasant for the developers, but they do not automatically make the existing software better: in order to benefit from these improvements, one would have to adapt the source code. This costs time and therefore money. All this just so that the software can be perceived by the outside world as it was before the adaptation?
A good argument for updating PHP is the improved performance. Although almost every new version of PHP has been faster than its predecessor, the leap was particularly noticeable with PHP 7.0. Therefore, you can benefit from the optimizations even without changes to the source code.
The PHP project is, despite massive – and partly unfortunately also justified – criticism of inconsistencies in language and design decisions of the past, very concerned about backwards compatibility. Most software developed for PHP 5.6 or even earlier will therefore run with PHP 7 without any significant changes.
Of course, a major version jump also almost inevitably brings with it some incompatibilities. However, the extent to which these have an impact on your own code base is – perhaps unsurprisingly – strongly related to the size of the jump. All so-called backwards compatibility breaks, i.e. incompatibilities with the previous version, are announced by PHP, sometimes over several versions, by marking certain functionalities as deprecated – "undesired". This is an indication that one should distance oneself from their use, and there is no reason to wait until the next PHP version is upgraded.
If you not only continue to develop your software yourself, but also keep the environment in which it runs constantly up-to-date, you only need to make small changes from version to version – if at all. One such possible change is to gradually activate strict type checking using declare(strict_types=1);
. It's almost frightening how often one becomes aware of small inaccuracies in one's own work only through this change – and asks oneself one or two times why the software has worked at all before.
After all, software rarely serves an end in itself. It should therefore be all the more important for a company to protect the investments it has made in development. This includes not only adapting to changed business processes and sufficient testing, but also keeping the components required for execution, such as language versions, libraries and tools up to date.
At least you'd think so. If you take a closer look at the last published access statistics of Packagist at the end of 2018, you will be surprised to find out that only about one third of the PHP installations accessing Packagist are from a current version that is fully supported by the PHP project. One third! A small ray of hope: The share of PHP 5.x has dropped to 15% since May 2018 and will hopefully soon disappear completely.
But why do so many users not work with a current version of PHP? One possible explanation would be that many of the packaged accesses are made by once set up fully automated systems that constantly download the same versions of the software, thus distorting the statistics. However, this problem would probably apply to both old and new versions and should therefore not distort the numbers too much.
Another part could be simply forgotten systems, which continue to do their work stoically, even if nobody (anymore) is interested in the result. Sounds unrealistic? Unfortunately no, as you can see from the installation attempts of PHPUnit: Besides of course many downloads via Composer and the PHAR archives, the installation continues via PEAR installer. Of course, since the end of 2014 – and thus for at least 4 years – no version of PHPUnit can be installed via PEAR anymore. But that doesn't seem to bother me very much, because until today many systems access the shut down server pear.phpunit.de
every day.
That PHPUnit is not alone here is proven by the PEAR project, which is just waking up from its slumber because the official pear.php.net server has been hacked . Instead of sending the PEAR installer and its infrastructure, which is no longer needed thanks to Composer, into a well-deserved retirement, unknown attackers had taken over the PEAR server and spread malware. Possibly undetected for months, a version of the CLI tool manipulated by the attackers was provided. Fortunately, the servers are now offline for the time being. Whether they will ever be reactivated remains to be seen and will probably depend not least on the reactions of users who miss the PEAR servers – or perhaps, hopefully!
However, most of the available packages are probably not very new and up-to-date, many externally hosted dependencies such as PHPUnit have been missing for a long time. But even on Packagist the situation is not necessarily rosy: Although big projects like Symfony, Laravel or NEOS and also well-known tools like PHPUnit, PhpSpec and Xdebug in current versions require at least PHP 7, in November 2018 almost 80% of the listed projects supported outdated PHP versions with their latest version as a minimum requirement. PHP 5 is still alive on Packagist: Almost 60% of the available packages support this version.
The compatibility with older PHP versions is not bad per se. However, whether it is worthwhile to consider versions that have not received any official support – some of them for years – for new releases is questionable. Even the official support is unfortunately not as easy to judge as it might seem. Debian Linux as well as most other major Linux distributions offer support for long discontinued versions of PHP and other components with their respective LTS versions for years to come. A change to a newer version is usually technically possible, but in the enterprise environment it is often not even desired for legal reasons.
In a world where more and more software runs in containers, the need for LTS versions should actually decrease dramatically. After all, if you are used to automatically create a new image for a deployment, you no longer have any reason to roll out obsolete software with the runtime environment. On the contrary: Keeping these systems up-to-date should be a clear goal for every team that understands DevOps.
The realization that any software needs to be maintained is nothing new. Interestingly, the consequences of neglect are as often ignored in software development as they are in other areas of everyday life. It is no coincidence that almost everywhere in the world mankind is struggling with a dilapidated and broken infrastructure. The bridge still holds ...