41 ms·

Obviously everyone has different situations. But if all you need are security updates, the Rails team has historically been very good about providing patches ev

Obviously everyone has different situations. But if all you need are security updates, the Rails team has historically been very good about providing patches even for unsupported releases. If they don't, porting is often fairly trivial anyway. I often see ronin [1] implementations of exploits very soon after a CVE so you can even test against your own app. Unfortunately, my point was more that you can't just not upgrade Rails. Eventually everything else you use will require newer Rails and upgrading at that point becomes extraordinarily difficult. E.g., ActiveRecord plugins often just monkeypatch the internals, which are naturally free to change from release to release. However, most gem authors don't want to test against multiple versions, so the latest becomes the only supported one and you have to upgrade "just because." [1] -- https://github.com/ronin-ruby/ronin/ https://github.com/ronin-ruby/ronin/

ch4s3 11y ago
That's all totally fair. I really wish people weren't so quick to monkey patch things, especially when it comes activerecord. "Eventually everything else you use will require newer 'x'", I think this is a problem even with non-frameworks. Imagine any core to your functionality lib getting far out of date. Dependency graphs are hard to manage over time.
- nirvdrum 11y ago
  Agreed. It just seems far more pronounced in the Ruby ecosystem. My experience with Python and Java is that both communities are okay with maintaining multiple versions of a library. And when you commit to that, you adopt practices like separate namespaces between major versions, which can make upgrading substantially easier. With a bit of trickery, you could even load two different versions of the same lib as long as their namespaces don't conflict. Ruby gems, on the whole, hardly ever employ namespacing so that option isn't even available. I don't see it so much as a technical limitation of Ruby, but simply the way the community has evolved. With other ecosystems, the emphasis is often on stability by sticking what's known to work. Abstractly they have the same dependency graph problems, but in practice their problems and solutions are quite different.

ch4s3 11y ago

That's all totally fair. I really wish people weren't so quick to monkey patch things, especially when it comes activerecord. "Eventually everything else you use will require newer 'x'", I think this is a problem even with non-frameworks. Imagine any core to your functionality lib getting far out of date. Dependency graphs are hard to manage over time.

nirvdrum 11y ago
Agreed. It just seems far more pronounced in the Ruby ecosystem. My experience with Python and Java is that both communities are okay with maintaining multiple versions of a library. And when you commit to that, you adopt practices like separate namespaces between major versions, which can make upgrading substantially easier. With a bit of trickery, you could even load two different versions of the same lib as long as their namespaces don't conflict. Ruby gems, on the whole, hardly ever employ namespacing so that option isn't even available. I don't see it so much as a technical limitation of Ruby, but simply the way the community has evolved. With other ecosystems, the emphasis is often on stability by sticking what's known to work. Abstractly they have the same dependency graph problems, but in practice their problems and solutions are quite different.