[stevebmark]

It's not easy to automate. As you know Github now works directly off the Rails main branch. They have both core Ruby and core Rails maintainers on staff. They have to find, fix, approve, and merge, introduced bugs every day, as well as deal with Rails bugs themselves in the main branch that emerge. This is a huge overhead cost for keeping software up to date, and does not (and should not) apply to any other company.

[byroot]

That's absolutely not a huge overhead, quite the contrary it has many benefits.

We do the same at Shopify, and running off the edge allow to catch bug much sooner and identify them much easier.

It also very significantly cuts down on maintenance cost because we no longer have to work-around bugs, we can fix them upstream and so a small update.

As for you pointing at the Rails 5 migration taking a very long time, it's true that certain major migrations were a pain this one in particular, but it's because a major API had been removed (attr_protected). We (both Shopify and GitHub) work with the edge also in part to make sure the community won't have to suffer this kind of harsh migrations ever again.

All this to say you are blowing things out of proportion. The Ruby and Rails teams at Shopify and GitHub are not an overhead, they pay for themselves, and any tech company as large as Shopify or GitHub you will find major contributors to the stack they use. e.g. There used to be a JVM team at Twitter (half smaller than Shopify even at peak).

[stevebmark]

I'm not surprised you don't consider the team you work on as overhead. But it is just that. This is a Rails only problem. This is not a problem that applies to other engineering ecosystems, because upgrades are easy to trivial in other ecosystems. It is a problem that shouldn't exist. It makes sense that the only way Shopify has found to do efficient Rails upgrades and keep using Rails is to dedicate a team to it and subsidize Rails core development. But this isn't a model other companies should follow.

I don't see the JVM team as the same thing as a team dedicated to working off a project's core. The JVM team looks closer to the YJIT project. Making a JIT also calls into question Shopify's scalability: Rails was slow enough that they allowed a JIT to be built internally? That's quite the trade-off to make.

[byroot]

> The JVM team looks closer to the YJIT project.

That's the same team (Rails + Ruby)...

> Making a JIT also calls into question Shopify's scalability: Rails was slow enough that they allowed a JIT to be built internally?

You are conflating scaling ability with language speed, there is of course some relation between the two, but it's mostly orthogonal.

At the scale of Shopify (several thousands developers) having a few people focus on improving Rails and Ruby is a drop in the bucket and payoff immensely.

Rails and Ruby are both Open Source projects not backed by for-profit organization. It's perfectly normal for an user of such project to contribute patches... That's how Open Source is supposed to work...

There is plenty of organizations contributing patches to the Linux Kernel (Google, IBM, etc). Using your logic that means Linux is slow enough that Google allowed a new scheduler to be built internally?

That's quite the silly line of reasoning...

[vidarh]

I have just spent weeks at $dayjob resolving Java dependency issues I wouldn't wish on my worst enemy. As much as I dislike Rails, it's nonsense that this is a Rails-specific issue.

[pelasaco]

guess what? 99% of the apps are not github, neither shopify. You add to your pipeline some automation with https://github.com/fastruby/next_rails and you are done. I'm maintaing a rails app from 2006, with more than 1000 LC (excluding the 2k specs and views) and we are running on rails 7.1. We had one critical moment around rails 5.2 , but after that we managed to keep our stack always up to date.

[stevebmark]

Did you really mean 1,000 and 2,000 LOC for tests? Or did you mean 1000k or something else? If you meant 1,000, that is an objectively tiny app, and not relevant to the difficulty of maintaining large Rails applications.

[pelasaco]

sorry, i forgot some zeros ;)

checking again:

CODE: 198235 LOC total

SPEC: 127708 LOC total