3 ms·

Code breaking for patches and security enhancements is widely viewed as unacceptable, but this is the first occasion I've seen someone accept to breaking change

Code breaking for patches and security enhancements is widely viewed as unacceptable, but this is the first occasion I've seen someone accept to breaking changes in a major release. Neither Rails 2 nor Rails 3 were fundamentally broken, and there's nothing stopping you from keeping an application on those releases.

nirvdrum 14y ago
In theory, there's nothing preventing you, but in reality it's just way too difficult. I put off upgrading to Rails 3 for a long time because of the rspec 2 fiasco and because Rails 2.3 was much faster. But, the problem is the rest of the ecosystem. Most gems simply don't provide changelogs. Virtually none will maintain compatibility with more than one version of Rails, despite how easy monkey-patching makes this. So, if you care about fixing security releases in your app, you need to maintain not just Rails, but also the code for every plugin you use. In one case I was told if I wanted the latest toys, I should upgrade to Rails 3, even when I offered to provide the Rails 2.3 compatibility branch. It's not a technical problem, it's a cultural one (and to be fair, those with opposing viewpoints don't view it as a problem). But, at the end of the day it's just not worth the headache. You need to ruthlessly cut your dependency graph or accept the potentially destabilizing upgrade.
- j45 14y ago
  I think what you said about theory vs reality is the gap of technical debt that gets created. It's a real and growing issue in any framework that is maturing. If what is today's leading edge will be legacy in the next 8-12 months, can a codebase get established and create value?
  - nirvdrum 14y ago
    It's hard to say. Other communities do this much better. Java is obviously the poster child for backwards compatibility, but Python is much better too. Ruby makes supporting multiple versions very simple in most cases, but there's no will to do so. For my part, I avoid anything that's a Rails plugin now. Time after time, I've found them to be a problem. Even if you decide you're going to upgrade to Rails 4, you need to update your entire dependency graph in one pass. Plugins targeting Rails 4 almost certainly won't target 3.x and not all plugins are going to be 4 ready on release day, so upgrading piecemeal is impossible.
- lobster_johnson 14y ago
  I don't know, we have a project that is still on 2.3.14 and Ruby 1.8.7, and we have not had any issues with compatibility. The old gem versions we have relied on all still work. And some of the gems we use are relatively new; for example, we use Dalli instead of the old memcache-client gem. The only issue has been with our deployment environment — there is just too much effort required to support both 1.8.7 and 1.9.3 on the same box, so this particular app is still running on separate boxes that are configured using legacy Puppet scripts.
  - nirvdrum 14y ago
    Well, the old gems will still work. But assuming you want to get any sort of security fixes, you need to backport all that yourself. I'm surprised you haven't run into more issues with gems targeting 1.9 now.

nirvdrum 14y ago

In theory, there's nothing preventing you, but in reality it's just way too difficult. I put off upgrading to Rails 3 for a long time because of the rspec 2 fiasco and because Rails 2.3 was much faster. But, the problem is the rest of the ecosystem. Most gems simply don't provide changelogs. Virtually none will maintain compatibility with more than one version of Rails, despite how easy monkey-patching makes this. So, if you care about fixing security releases in your app, you need to maintain not just Rails, but also the code for every plugin you use. In one case I was told if I wanted the latest toys, I should upgrade to Rails 3, even when I offered to provide the Rails 2.3 compatibility branch. It's not a technical problem, it's a cultural one (and to be fair, those with opposing viewpoints don't view it as a problem). But, at the end of the day it's just not worth the headache. You need to ruthlessly cut your dependency graph or accept the potentially destabilizing upgrade.

j45 14y ago
I think what you said about theory vs reality is the gap of technical debt that gets created. It's a real and growing issue in any framework that is maturing. If what is today's leading edge will be legacy in the next 8-12 months, can a codebase get established and create value?
- nirvdrum 14y ago
  It's hard to say. Other communities do this much better. Java is obviously the poster child for backwards compatibility, but Python is much better too. Ruby makes supporting multiple versions very simple in most cases, but there's no will to do so. For my part, I avoid anything that's a Rails plugin now. Time after time, I've found them to be a problem. Even if you decide you're going to upgrade to Rails 4, you need to update your entire dependency graph in one pass. Plugins targeting Rails 4 almost certainly won't target 3.x and not all plugins are going to be 4 ready on release day, so upgrading piecemeal is impossible.
lobster_johnson 14y ago
I don't know, we have a project that is still on 2.3.14 and Ruby 1.8.7, and we have not had any issues with compatibility. The old gem versions we have relied on all still work. And some of the gems we use are relatively new; for example, we use Dalli instead of the old memcache-client gem. The only issue has been with our deployment environment — there is just too much effort required to support both 1.8.7 and 1.9.3 on the same box, so this particular app is still running on separate boxes that are configured using legacy Puppet scripts.
- nirvdrum 14y ago
  Well, the old gems will still work. But assuming you want to get any sort of security fixes, you need to backport all that yourself. I'm surprised you haven't run into more issues with gems targeting 1.9 now.