4 ms·

There are a number of perverse incentives going on here: - Rails needs something opinionated and "new" every so often to remain relevant. - Workers, consultan

There are a number of perverse incentives going on here: - Rails needs something opinionated and "new" every so often to remain relevant. - Workers, consultants, etc., benefit from being familiar with the latest rails, so many projects are upgraded that don't need to be. - New versions break lots of gems and useful online tutorials, increasing the value of experience relative to aptitude. So now, across the world, lots of teams will remove perfectly good code and divert lots of attention to upgrading to Rails 5 for no apparent reason or simply that a higher number is viewed as better. Contrast this with the node ecosystem where libraries tend to be smaller and significant version bumps typically take an hour or so to accommodate at most. The worst part is that if you engineered an alternative to action cable (for example) into your app, Rails 5 makes your approach seem outdated for no reason.

ch4s3 11y ago
- If you upgrade a project "just because" then you're doing it wrong. That isn't the fault of the rails team. - New versions don't break that many things that aren't tied directly to how rails works. Most general gems will work just fine, and a lot of tutorials from 3.2 are still more or less usable with minimal googling. Generators work the same, active record's api hasn't changed much, action view works the same way. And don't get me started on the mess that a node dependency graph can become.
- nirvdrum 11y ago
  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.
        11y ago

ch4s3 11y ago

- If you upgrade a project "just because" then you're doing it wrong. That isn't the fault of the rails team. - New versions don't break that many things that aren't tied directly to how rails works. Most general gems will work just fine, and a lot of tutorials from 3.2 are still more or less usable with minimal googling. Generators work the same, active record's api hasn't changed much, action view works the same way. And don't get me started on the mess that a node dependency graph can become.

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