PHP-upgrade: Veel redenen om het wèl doen

"Er zijn meerdere redenen. In nieuwe versies worden bugs gefixt en bijvoorbeeld security vulnerabilities. Die kunnen in zichzelf grote gevolgen hebben. Op een gegeven moment wordt een oude versie uitgefaseerd [zoals maandag gebeurde met PHP 7.2, red]. Dan worden er geen bugfixes meer op uitgevoerd. Een andere reden is performanceverbeteringen. Tot slot kunnen nieuwe taalfeatures het leven van programmeurs makkelijker maken. Ik denk dat de opwaardering van PHP 7 naar 8 vooral om die laatste twee gaat: snellere executie, nieuwe convenience features zoals "syntactic sugar", shorthand notaties etc. Maar er zijn ook verbeterde foutmeldingen. In de overgang van PHP 7.x naar PHP 8.0 zitten wel wat backwards incompatible ("breaking") changes, maar die zijn vrij kleinschalig voor zover ik kan zien, en gelukkig goed gedocumenteerd."

Wat zijn de risico's om oudere versies van PHP te blijven gebruiken?

"Het risico is stagnatie: uiteindelijk gebrek aan support en bugfixes, en kwetsbaar blijven voor mogelijke security problemen. Dit geldt eigenlijk voor elke taal. Een case-in-point: Facebook heeft veel geld en moeite geïnvesteerd om de problemen omtrent snelheid en betrouwbaarheid van PHP aan te pakken; één resultaat hiervan is bijvoorbeeld Hack, een dialect van PHP. Maar goed, niet iedereen heeft de resources van een Facebook natuurlijk..."

Hoe kunnen organisaties verleid worden om ondersteunde versies te gebruiken?

"Leveranciers van programmeertalen zouden het makkelijker kunnen maken door tools aan te bieden om migratie-assessments te doen, of zelfs de migratie (deels) te automatiseren. Ik geloof dat de Python community zoiets gedaan heeft toen ze overgingen van 2.x naar 3. Dat was een grote stap. Googles Go heeft een migratietool die ontwikkelaars kan helpen als API's van standaardbibliotheken veranderen. Op z'n minst zou ik verwachten dat er een tool zou worden meegeleverd die potentiële knelpunten in een code-base kan aanwijzen. Aan de andere kant: leveranciers kunnen migratie makkelijker maken door voor alles backwards compatibility in het oog te houden. Met name Java en C# zijn daar goed in, maar het heeft beperkingen: je kunt feitelijk niks uit de taal of standard library weggooien. En als backward compatibility niet houdbaar is, een transparant proces van "deprecation": vroeg aankondigen dat iets gaat verdwijnen, opdat klanten zich stapsgewijs kunnen voorbereiden, en in de tussentijd de compiler warnings laten produceren."