Breaking Changes vs Infinite Support

A long time ago I was a web developer who used CodeIgniter and I appreciated the fact that they supported some pretty old versions of PHP as newer and newer versions came out. My web host at the time took like 8-12 months to add support for a newer version of PHP and laziness got the best of me - so old PHP applications still working on a framework were great.

At some point my opinion started changing when features of a newer version of PHP looked intriguing, but the framework couldn't leverage them instead forcing the usage of plugins or 3rd party code that hovered at a higher PHP requirement than the framework itself.

At some point a challenge started developing for CodeIgniter such that it was difficult to support new versions of PHP without dropping old versions of PHP. Some changes were just that difficult to maintain compatibility, but things like poly-fills and workarounds kept it going. An interesting thing I noticed as well during this time is plugins and packages around the framework generally followed its supported versions which kept everything in the community back from the newest and greatest native language features.

When the rumored CodeIgniter 3 came out it moved the minimum version of PHP to 5.2 (from 5.1), but encouraged PHP 5.4+ or greater to be used. A couple months later PHP7 ended up being released and my attachment to Codeigniter faded. As Laravel entered the picture for me I was blown away by the modern PHP requirements and developer experience.

Even more so when a new PHP version came out - Laravel had it supported before its release date which was no easy task when it depended on a bunch of dependencies. I blogged about that before, but it was such a breath of fresh air to have a framework dragging the industry with it as they dropped older PHP versions on nearly every major release. The benefit also being that every dependency they depended on also got that treatment or an alternative was produced.

Now switching over to fastlane I've been maintaining it for a few solid months now and the biggest thing holding me back was fastlane still supporting Ruby 2.6 which was released in 2018 and support ended in 2022. Folks want the new Ruby versions but there comes a cost for trying to support the new without dropping the old. How many times do I need to upgrade a package for a new Ruby version, but that newer package bumps the minimum past fastlane's requirement?

Apple computers actually ship a version of Ruby for historic reasons and that is Ruby 2.6 on the system. That meant fastlane could work out of the box on a Mac computer, but in most cases the outdated system version of Ruby was not preferred. So preparing to say good bye to Ruby 2.6 was a big deal - we'd no longer support the version of Ruby that comes preinstalled.

We haven't even discussed the developer cost of supporting such old versions on fastlane. Our CI system (CircleCI) would announce the shutdown of older Mac runners - the newer ones had a new default version of Ruby so we needed to compile older versions of Ruby just to test the codebase. Docker was added into the picture to control the exact dependencies of old things we needed in order for build systems to pass. It became a lot of work just supporting the old versions and with no money coming in and no business footing the bill for support - it made sense.

I started a push internally to actually move the needle forward and have fastlane follow the EOL dates of the Ruby language. We said good bye to Ruby 2.6 after a month of discussion and agreed to emit a little warning into output to warn end users of the impending future.

WARNING: Support for your Ruby version (2.6) is going away. fastlane will soon require Ruby 3.2.0 or newer.

We have a decade of cruft to clean up and no Ruby jump is easy, but we are starting the slow journey of modernizing dependencies, fixing security issues, dropping old Ruby versions (Ruby 2.7 WIP) and trying to bring fastlane back to a pioneer of build tools instead of a decaying passenger.