LTS — Delaying the inevitable.
by Johnathan Dell
One of the most notable causes of change anxiety I have seen during my career working for various tech companies is not knowing how significant or breaking changes could affect the entire software development life cycle (SDLC). This is purely an opinion piece, take it with a pinch of salt.
Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. [1]
Choosing long-term support versions — which has long been the approach of medium- to large enterprises — has a definite advantage, as there is a very small chance of breaking changes being introduced into their processes.
The downside of sticking to long-term support is that these breaking changes are usually improvements to the software or new features that optimise and improve on development processes.
Staying on stable versions becomes problematic once these long-term versions are no longer supported, and in most cases, the transition to a newer stable version does not happen until well past the period of support for an older version.
Stability aside, what happens when the platform or technology you are keeping on a stable version becomes outdated and you have to upgrade to a newer stable version?
For this example, I’ll focus on Laravel. The maintainers for Laravel have recently announced an annual major release schedule for the Laravel Framework. The current LTS version is version 6 and the next will be version 9.
As the number of businesses and individuals using Laravel has grown substantially, I feel like now is a good time to update our release schedule to help ease the maintenance burden on our community. [2]
Once the support period for version 6 is over, teams will need to transition any existing systems over to version 9, and not only implement any breaking changes within version 9, but also those that may have been introduced between 7 and 9 as well.
The burden often falls on the development team to make up this ground in-between versions, and the risk of upgrading multiple versions in one go is greater than upgrading periodically as newer versions mature.
The argument can be made that upgrading between versions has a cost and/or time implication for either the company or client, however this is negligible when taking into account that the cost and time expense becomes exponentially more costly when delayed.
So what is the answer?
In my honest opinion, there is no one-fit-solution here, however the takeaway is to not delay the inevitable, be transparent with the client, and factor the cost of short- and long-term upgrades into the SDLC, to the benefit of all parties involved.
Be cognisant of when major versions become available, plan ahead and trust your team to ensure parity between versions. Lining up these upgrades with a client’s short-term expectations and long-term goals will benefit the continual improvement of their product.
