3 ms·
Perhaps you use a smaller set of dependencies, wait a while before upgrading, or got lucky? It was necessary for us during the ruby 3.0 and 3.1 upgrades, and du
by nevinera 4y ago
Perhaps you use a smaller set of dependencies, wait a while before upgrading, or got lucky? It was necessary for us during the ruby 3.0 and 3.1 upgrades, and during the rails 7.0 upgrade.
In particular, the change during ruby 3.0 to the handling of keyword arguments vs final hash params broke a _lot_ of gems (like memoist and ruby-kafka's datadog integration), that wrap arbitrary methods, because when they wrap keyword-argument methods, they passed the arguments into the wrapped method as hash-args instead.
I expect that the longer you wait after a release to upgrade, the less it's an issue - the ecosystem takes time to catch up. We've been staying fairly on top of the upgrades.
- ufmace 4y agoCould be the time thing. Some of our apps at work have big-ish gem sets, but our ruby version upgrade cadence is much closer to update the version when the current one is about to go out of support for security updates than grab the new hotness within a week of it being released.
- nevinera 4y agoOh yeah, that'll definitely do it. Our prior policy was to only adopt a version of rails when it's no longer the newest version of rails, and even that was enough to avoid most compatibility issues. We currently tend to adopt new versions of rails and ruby about a quarter after they are released (I wouldn't recommend "within a week" to any large project). It's worth noting that the reason there aren't a ton of compatibility issues 9 months after those things are released is _because_ of shops that perform the upgrades, find the issues, and report or solve them before then. The later you choose to go in the cycle, the less you'll be impacted, and the less you will contribute.