4 ms·

While upgrading "just because" should be avoided (and indeed, DHH stated as much in a keynote at one of the RailsConfs), that's exactly the approach the Ruby co

While upgrading "just because" should be avoided (and indeed, DHH stated as much in a keynote at one of the RailsConfs), that's exactly the approach the Ruby community/ecosystem have adopted as a whole. Most Rails plugins don't maintain compatibility with multiple versions. And if you use something that overlaps with Rails's dependency graph, you're going to have to deal with that in one way or another. In Ruby and Rails, you basically have to keep updating regardless of the changelog simply to amortize your costs. If you fall too far behind then when you invariably do need to upgrade a dependency, you're going to have to pay all that cost in one swoop and the complexity of that amps up considerably.

gkop 11y ago
I missed the keynote, but according to the OP the release of Rails 5 means "4.1.x and below will essentially be unsupported". My advice is always to upgrade 3-6 months after a major or minor release. After 3 months so that other people have exhaustively documented their troubles and resolved incompatibilities in the libraries they maintain. And before 6 so that Google results for common issues are still fresh. So I think putting it in terms of "just because" is not really very helpful. In a sense my upgrading in the 3-6 month interval is "just because", but doing it this way keeps the overall maintenance burden to a minimum, since I do have to upgrade sooner or later in order to receive security updates.
- nirvdrum 11y ago
  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
While I agree that you're probably going to be upgrading in part to amortize your costs, it's not like you're getting no value out of it. The upgrade from 4.1 to 4.2 had significant speed and stability gains in active record. And recent versions of a lot of popular gems are both faster and more secure.
- nirvdrum 11y ago
  Don't get me wrong, there are reasons to upgrade. But all other things being equal, you may very well not need the newer features. Rails has an astoundingly good track record with backporting security fixes, going so far as to provide monkeypatches for those that can't upgrade their gems for one reason or another. Upgrading Rails can force upgrades on a lot of other things, however. And new bugs get introduced all the time. Performance regressions happen. Etc. There should be a more compelling reason to upgrade than the version number changed, given the additional risk you take. Unfortunately, that's often not the case.

gkop 11y ago

I missed the keynote, but according to the OP the release of Rails 5 means "4.1.x and below will essentially be unsupported". My advice is always to upgrade 3-6 months after a major or minor release. After 3 months so that other people have exhaustively documented their troubles and resolved incompatibilities in the libraries they maintain. And before 6 so that Google results for common issues are still fresh. So I think putting it in terms of "just because" is not really very helpful. In a sense my upgrading in the 3-6 month interval is "just because", but doing it this way keeps the overall maintenance burden to a minimum, since I do have to upgrade sooner or later in order to receive security updates.

nirvdrum 11y ago
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

While I agree that you're probably going to be upgrading in part to amortize your costs, it's not like you're getting no value out of it. The upgrade from 4.1 to 4.2 had significant speed and stability gains in active record. And recent versions of a lot of popular gems are both faster and more secure.

nirvdrum 11y ago
Don't get me wrong, there are reasons to upgrade. But all other things being equal, you may very well not need the newer features. Rails has an astoundingly good track record with backporting security fixes, going so far as to provide monkeypatches for those that can't upgrade their gems for one reason or another. Upgrading Rails can force upgrades on a lot of other things, however. And new bugs get introduced all the time. Performance regressions happen. Etc. There should be a more compelling reason to upgrade than the version number changed, given the additional risk you take. Unfortunately, that's often not the case.