A. Upgrade to the latest major/minor version each year, if you can.
As a general rule of thumb, Ruby on Rails has released a new version on nearly an annual basis. The core team has typically aligned these with the annual RailsConf so that there are new features and updates to demo in keynote talks.
This has consistently been the case for nearly each of the last 15 years...give or take a few.
I also understand that it can be a challenge for teams to plan and prioritize upgrades. I'll touch on that more later.
First, let's get down to brass tacks. We need to assess your situation.
What is the newest version of Rails?
The community is currently kicking the tires on Rails 6.1 release candidates.
Note: Due to COVID-19, the release cycle appears to have slowed down a touch.
What version is your app currently running on?
If your Rails application is not running on either 5.2.x or 6.0.x (or newer)...your application is at risk.
| Rails Version | Status | Latest Patch |
|---|---|---|
| 6.1.x | 💚 Supported | Nov 2020 |
| 6.0.x | 💚 Supported | Oct 2020 |
| 5.2.x | 💚 Supported | Sept 2020 |
| 5.1.x | 🚨 At Risk | March 2019 |
| 5.0.x | 🚨 At Risk | March 2019 |
| 4.2.x | 🚨 At Risk | May 2020 |
| 4.1.x | 🚨 At Risk | July 2016 |
| 4.0.x | 🚨 At Risk | Jan 2015 |
| 3.2.x | 🚨 At Risk | Sept 2016 |
...you get the idea.
The older the version, the more at risk your application is.
Do you have multiple Ruby on Rails applications and want to have someone gather this information? We have a free google sheet template for you to document these details.
I encourage you to steal this template!
At risk of what, exactly?
Great question!
Like any software running on your laptop, smartphones... the software that we write to power our web application also has security vulnerabilities that are found. When these issues are found (usually by the good/friendly hackers who are kind enough to share what they discover), the Ruby on Rails Core Team will apply security patches and release a small update.
For example, if you are running on 5.2.9, they might release 5.2.10 to patch the security hole.
In theory, a developer on your team should be able to quickly bump up to the new version in the Gemfile with one line of code change, a run through your automated tests, and a deploy. ..and that known security hole is no longer a possible backdoor for the unfriendly hackers out there.
Note: this can be automated!
What about bug fixes?
The other benefit to staying up-to-date is that there are 🐛 bugs found within the underlying Ruby on Rails framework from time-to-time.
If they are critical enough bugs, the Rails team release will release a small patch for those.
Learn more about the official Ruby on Rails Maintenance Policy
What version are most Rails applications running on?
Every two years, Planet Argon surveys the Ruby on Rails developer community and shares our findings. This year, we have 2,049 members of the community share a number of details about their applications.
Based on the survey, ~62% of respondents said they were running on either 5.2.x or 6.x. (source)
Are you part of the other 38% that are running on an unsupported version?
How often should you update your version of Rails?
In an ideal world, your team would be aiming to stay up-to-date with Rails as new versions are released. But, we live in a world where each team has a wide range of priorities to juggle. Without a cohesive process to follow, teams will put upgrades into a someday/maybe list.
We understand why this happens.
Upgrades feel like a lot of work for little immediate payoff. However, this has a compound effect in that it results in making the upgrade path far more time consuming and risky to explore. As developers, we are risk-averse and product owners are worried about upgrades being drastically underestimated.
The reality is that some of the major version upgrades are far from trivial. Third-party dependencies tend to be a lot of the challenges that those upgrades need to navigate.
When everyone is afraid of breaking things in a working application – the decision gets delayed for another time, place, or even worse...left for future people added to your team to have to deal with.
As new engineers join your team and learn that keeping the applications up-to-date isn't part of your team's workflow, they will start to assume that it is not considered important within your company culture.
Note: Delayed upgrades can definitely impact your employee retention, too. When they aren't able to leverage newer features, libraries, and/or tools in Ruby on Rails, they may start to daydream about finding a new team where the grass may (or may not) be greener.
Regardless of how you spin it...this is problem. A problem that your team can (and needs to) solve!
Can't you just hire a professional to upgrade for you?
Yes! (...but I have written 3 Reasons Why You Shouldn't Outsource Your Rails Upgrades to explain my concerns about that as a long-term "solution").
Several companies have hired our team over the years to handle the underlying upgrade. We enjoy rolling up our sleeves and getting our hands dirty.
However, we believe that a better approach is to provide guidance to teams on handling their own upgrade.
Interested in helping get your team started? Take a look over our Rails Upgrade Kickoff service and fill out the form if you'd like to talk shop about how we can help your team manage their Rails upgrade process.
This was originally posted on blog.planetargon.com
Top comments (0)