Laravel: Goodbye LTS
You can blame PHP all of you want
In the age of agile software development, where features are not planned for the next release but for few months away, a “Long Term Support” has become something like a safe bet for any project manager. No need to keep updating to receive the latest features, bug fixes and security patches, without breaking your existing code. Find the LTS version, and your projects will live a long life.
The problem of PHP its that. To keep PHP modern with new features and performance optimizations, something that almost killed it a decade ago, resources must be spent to keep moving forward and deprecating the old.
That’s why not only Laravel, but any other PHP-based project, will stop launching with LTS promises, but rather, a more steady support timeframe.
It’s all PHP fault
In case you don’t know, PHP has a clear stance on support. Every major or minor new version has two years of active support with fixes and optimizations, while a third is reserved for only security updates.
You can see in the above graph displayed at the official site, all new language versions have two year lifetime after they’re released. Since releases have become yearly, the PHP team only has to support the latest two version actively, while a third one only for security updates.
As you can see, making a project based on a newly released version of PHP may work without hindrances for 3 years, at best. There is always people looking for vulnerabilities on old code, and if one is discovered for an unsupported version, the responsibility now its entirely the developer for not reading the manual.
Resources are finite, and manpower too. Keeping developers busy with old code means less time for new code and to keep the language relevant.
Prepare for a world without true LTS
Let’s think about trying to make an LTS release for a big PHP project. You set the latest stable version, and you work around the language features it has.
To keep it compatible with the whole ecosystem, you will be bound to support the language it was written for no more than two years, if not less. More than that and you will see the problem: everybody will have moved on, and you may risk using a vulnerable language or out-of-date dependencies. Avoiding this means keeping your foot on the accelerator.
That’s why projects like Laravel and others are removing LTS promises from the list. You cannot ask to keep older versions relevant if you want the ecosystem to keep moving forward. Luckily for us, PHP updates have been very friendly for developers, and haven’t breaking the Internet every year.
On the other hand, staying ahead of the curve is a point of discussion around many projects, like the Symfony framework. Do you support the latest stable with the new features, ensuring more active support years, or you ensure a broader audience with the minimal stable? Do you have the manpower to support both versions actively with feature parity?
In any case, no LTS it’s both a blessing and a curse. Sure, projects will be able to move forward and enable functionality that the ecosystem enables them to. That also means to, at least every year, fix and upgrade.
At least, with this approach, working on PHP means having a job.
