When is the right time to upgrade your dogs to the latest software version?

A new software version is always an exciting prospect, they can teach an old dog new tricks and potentially make her run faster than before on the same old legs. That is the magic of software, bringing new capabilities seemingly out of thin air. While it is easy to groom your beloved Aibo with the latest software update, updating a whole pack of dogs might not be. Different ages, models, versions... It can get complicated.

Putting robot dogs aside, the situation is the same for virtually any piece of software. In a simple scenario a major upgrade can be a humdrum operation; Say you upgrade your hobby project to the latest major release 15 minutes after launch, take another 15 to whip up a quick blurb on how easy it was to upgrade, post it to Hacker News and let the audience marvel at your life in the seventh heaven of bleeding edge.

The above is a true story, and is pretty amazing. Today the software industry moves at an exhausting pace. The continuous stream of updates provided to frameworks and libraries goes on day and night, every day there is a prospect of an upgrade, big or small. It is also part of the lure of the omnipresent microservices architecture where systems are constructed from small independent and decoupled pieces of software.

No microservice is an island

But in reality a microservice is not 100% isolated from the outside world. An abundance of shared code is used, and it can take time to get all the parts to be compatible with the latest baseline software version. Say if you were to use Node.js it is likely that you have thousands of dependencies from the NPM catalogue. You can be ready to go in 15 minutes, but it's unlikely that the entire ecosystem is.

Herding dependencies is easier with platforms like Go or Deno, which have a more extensive standard library, but still you might need to tweak your own codebase quite a bit for a new a major version. That depends on the backwards compatibility changes, how conservative the project leadership is, and ultimately pure luck. 🍀

Obviously there is no single timeline on when you can upgrade to a new version. For cases where you have few dependencies, and the benefits (often improved performance) are so beneficial that you can go for an upgrade in days or weeks of the launch. Especially if you've already prepared in advance by working with betas and release candidates as Arnold Palmer put it: The more I practice the luckier I get.

Case Ibexa DXP and PHP 8.0

For Ibexa DXP our core backend technology is built the Symfony framework that in turn runs on PHP. For both of these there are new versions arriving in late 2020. The Symfony framework will receive a new 5.2 version. As per semantic versioning this is a minor version, which will be compatible with the current Symfony 5.1 release used in Ibexa DXP 3.2. The upgrade is planned for Ibexa DXP 3.3 LTS due in early 2021.

For PHP 8.0 things are more tricky. The new version has some interesting new language features and increased performance potential with some caveats:

Regarding performance JIT seems to be a mixed bag here [for PHP 8.0], slowing down at low concurrency and providing a significant improvement to throughput over OPCache Preloading only. More investigation needed, but here the case is not clear as it could hinder performance. JIT seems like something to be considered case by case for PHP.
- PHP 8.0 and 7.4 benchmarks on Symfony 5.2

For us to upgrade Ibexa DXP to support PHP 8.0 we need to make sure our software is validated with it and that the PHP ecosystem (including Symfony and a number of other libraries) is good to go with this as well. With all that in place we could achieve technical compatibility with PHP 8.x so that it will run with it. Nothing has been decided, but we could potentially add unofficial support for PHP 8 in Ibexa DXP 4.0. This doesn't mean you couldn't technically run Ibexa DXP on PHP 8.0 before 4.x, but for us to provide support for our software we need to guarantee compatibility.

Providing forward compatibility is one thing, but backwards compatibility is where it gets trickier. As software engineers our team would like to have access to the latest language features. But we also need to maintain discipline to make our software useful in as many environments as possible. Since Ibexa DXP is a development platform, we cannot make PHP 8.0 a requirement before it is commonplace.

But while our hands are tied from using some of the new capabilities in 8.0 until it becomes a hard requirement, it does not limit our partners and customers to use it from the day we officially support it and when it works on their specified environment. Implementation projects are free to use the latest syntax and other features, since ownership of that code belong to the integrators building on Ibexa DXP technology.

Conclusion

Making a call about an upgrade is striking a balance. Is the upgrade worth the risk, or should you follow the principle If it ain't broken, don't fix it. Say for a robotic racing greyhound, would you do an upgrade that would make her 9% quicker but also potentially turn her into a hellhound at the time of a full moon? Not a realistic scenario, but a business can suffer serious damage from a botched software upgrade.

For software vendors this is even more difficult, moving forward and fixing technical debt while maintaining backwards compatibility can be done. But it's a lot more work to do so, and does require consideration for the long term rather than quick wins. But the key here is continuous evaluation, and tracking the market trends. Up-to-date and well maintained software is not only more relevant for business, but is also more attractive for developers to work with. This is why we at Ibexa already looking into and talking about upcoming technologies, even if official support is not yet decided upon.

Regardless of whether you're an end user or purveyor of software, you should consider at least the following things before proceeding with a software upgrade from the perspective of that specific version — in the short, medium and long term:

• Readiness of your codebase?
• Maturity of the ecosystem?
• What benefits would you get?
• What risks are there?
• Do you need to be able to roll back? Can it be done?
• Is the time suitable for the update?
• Do you have the resources for the update?
• Is delaying just pushing technical debt forward?

Sometimes the right choice is to upgrade right away to keep your application fresh and up-to-date, as leaping multiple major versions can be more work than upgrading one by one. Also one option is that an application should not be upgraded. If the piece of software is scheduled for sunsetting, then you should perform only critical updates and spend the time and effort elsewhere. Lifetime of a codebase is limited; At times this is by design or circumstance, but more often due to lack of regular maintenance.

At Ibexa we build future-proof software, but keep an eye on backwards compatibility.