2024-07-12 –, REPL (2, main stage)
When Julia 1.0 was released several years ago, we were faced with the challenge of migrating over our large Julia 0.4 codebase while making sure our customers didn't notice a thing. This talk is a story about reassessing life choices, keeping customers happy, and a quick build, slow release, 5 year, 40 step migration from 0.4 to 1.6. We hope to never have to do this again!
We started our Julia journey with version 0.2 over 10 years ago, and upgraded fairly quickly up to 0.4.7 as new versions were released. Then we started getting more customers, and our APIs stabilised, and migrations became expensive, so we sat at 0.4.7, watching every quarter as various dependencies reached the end of their supported lives.
Given that migrations were expensive, we knew that whenever we migrated, it we'd have to make it count for many years to come. We started migrating our code to 1.0, deciding to skip all the advice about migrating to 0.7 first. While this was happening, Julia moved to 1.1, 1.2, 1.3, 1.4, and 1.5, so we decided to jump to 1.5 instead, and then Julia released 1.6.
Over the course of the migration we developed a series of 40 steps that allowed us to change the underlying library while requiring only minimal changes to our customers' code.
In this talk, we will quickly go over some of the more surprising changes we've had to make. We will not discuss plans for 1.10 or 1.11.
Philip Tellis is a geek who likes to make the computer do his work for him. As Principal RUM Distiller at Akamai, he analyses the impact of various design decisions on web application performance, scalability and security. He is the creator of "boomerang" -- a JavaScript based web performance measurement tool.
In his spare time, Philip enjoys cycling, reading, cooking and learning spoken languages.
He has been developing with Julia since version 0.2 and recently completed a large migration from Julia 0.4 to 1.6.