When upgrading from Rails 3.0 to 3.1, one of the common issues we face is the breaking change in ERB syntax for helper methods. This change impacts form_tag, form_for, content_tag, javascript_tag, fields_for, and field_set_tag.

The main issue is that these helper methods in Rails 3.1 now require the use of <%= %> to output content, whereas in Rails 3.0 (and earlier), they used <% %> without needing to explicitly output the form content. This change is not backward-compatible, and applying it across a large codebase can be quite tedious when we are using our method of dual booting an application to do an upgrade.

In this article we will explore a few possibilities we have uncovered in the past few years while doing these upgrades.

Sinatra is known in the Ruby world for being a lightweight framework for building Ruby web applications with minimal effort.

Over time Sinatra has been through many versions, and sometimes it gets complicated keeping track of which versions of Sinatra are compatible with which versions of Ruby. Therefor, we made a handy chart!

How many times have you or someone on your team brushed off a failing build with a casual, ‘It’s fine, it’s just a flaky spec—ignore it’?

If you’re nodding in agreement, you’re not alone. It’s a scenario familiar to many of us, especially when dealing with sprawling monolithic projects and untouched code sections.

Late last year our team members headed to beautiful San Diego to join the incredible Ruby community at RubyConf 2023. Attending the conference is always a highlight, and we were excited to participate as a sponsor and engage with attendees, learn and share expertise, and have some fun.

The Ruby community is special. It has an incredibly inclusive and supportive culture that feels different than other languages. It was great to take some time to come together and enjoy the community’s hard work, network, and plan for the future.

In the first article of this series, we discussed How Much Does It Cost to Upgrade Rails based on our historical data working on over 100 upgrade projects. In this article we’ll discuss how to minimize the cost once you’ve decided to move forward on an upgrade so your team can continue to focus on valuable product feature or roadmap work.

Working with our team of experts to upgrade your Rails application allows you to stay compliant and take advantage of the benefits and security updates of a supported version, while also letting your team focus on revenue-generating initiatives. Still, it can be a significant investment, especially, as we covered in the previous post, if your project requires a high level of manual QA, for example.

There are, however, ways to reduce the time (and therefore cost) it takes to upgrade your Rails application when working with an external team. In this article, we’ll cover a few different strategies. Does it mean you can’t upgrade unless you do all of this? No, it doesn’t. Being an Agile team allows us to adapt to your process and workflow and work with any team to get the upgrade done. However, employing at least one of these strategies can make your upgrade more cost-effective.

Most people and companies that we talk to about upgrades assume that we generally help organizations that need to migrate to the latest Rails version.

However, this isn’t necessarily the truth. Instead, we mostly perform Rails upgrades for companies who are all the way back on Rails 3 or 4. To give you a better understanding of how common it is for companies to be on much older versions, this is a general list of our statistics from the past few years.

• Rails 2.3 - 3.2: 5 - 15 upgrades
• Rails 3.2 - 4.2: ~40 upgrades
• Rails 4.2 - 5.2: ~40 upgrades
• Rails 5.2 - 6.1: ~10 upgrades
• Rails 6.1 - 7.1: ~10 upgrades

We generally work with a lot of large, well established companies, so how did these successful companies fall so far behind, and how can you help your company to never need to hire us?

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 7.0 to version 7.1.

There have been a lot of changes over the years in asset management for Ruby on Rails applications. The main question, after all the madness, is… “What should I do if I need to upgrade my Rails application?”

In this article we will talk about the options we have for each version jump.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 6.0 to 6.1.

One of the steps we recommend taking when doing an upgrade for any Rails version is to dual boot the application with your current Rails version and your next rails version.

This is important because it allows you to quickly run the test suite for both versions, having dual booting available allows you to debug and also revert to your current version in a much simpler fashion.

However, sometimes changes that you make for the new version of Rails may not be compatible with your current version of Rails. This means that you will need to use a few different techniques to get both versions to be able to use the dual booting and run smoothly.

Contributing to open source projects is a big part of our philosophy at OmbuLabs. It’s even written into our values. Some of us like to contribute to open source even in our spare time!

Recently we have been thinking about what guidelines we should follow when starting a new open source project, and also about how to organize and keep track of the ones we contribute to.

This article will give you some tips on keeping those open source projects organized, and also how to start them off on the right foot.