FYI, here's what's new specifically for ActiveRecord 4, relevant for those of us who are using other frameworks (Sinatra, Padrino) that leverage Rails components:
OT performance rumination: I've not run tests on Rails' performance in this capacity, but I've always thought that the runtime gymnastics to pluralize model names would be a big drag on Rails performance. I'm guessing something's cached, but I've never understood the 'opinion' that a class should be 'Person' and the table name should be 'people'.
This is a really nice and handy guide, thanks! On a side note, having coded in many languages, I'm still a little at a loss for words that code breaking with new versions is tolerated.
Several of my talented friends spend too much time precariously managing their old Ruby codebases. I hope it keeps improving to make life easier.
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.
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.
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?
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.
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.
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.
This is a question of taste really. Do you favour continuous improvement or stability? Personally I prefer the continuous refinement approach that rails takes. It's definitely not for everyone though.
With a mindset of today's leading edge "way" being tomorrow's legacy.. one is creating technical debt that will be abandoned on older versions without extensive updates.
A black and white view on a framework being opinionated definitely costs more developer hours in some ways (which it could save up front).
I want to be extremely careful to not go near any religious debates about frameworks, or as you put it very well, preferences.
There is no perfect or ideal tool. Having open enough conversations about the tools we use and the reality we sometimes face without trying to be apologists or explain it away is essential.
I do wonder if many people have yet to have a relationship with a codebase they started as the leading edge, which stays stuck on an old release that becomes more and more expensive to upgrade. Does one really end up ahead in that case having to repay technical debt caused by the philosophy of a framework?
Maybe there's a finer line that can be drawn between the fantastic benefits of a framework that are not likely to change, and a way to work in approaches that may come and go?
Like any framework, it will have mature whether it likes it or not, I just hope it's for the better like everyone.
As bad as breaking changes sound, keeping historical baggage isn't ideal as well. I don't know about your friends, but if this is all that has changed, it would be a simple migration provided you already are on 3.2.
I'm referring to Rails apps that are being maintained in their current states in v1, 2, 3 and now beyond. The ability to maintain them in their current version (or upgrade) depending on what an updated gem does, or does not fix can be quite a challenge.
Well, if you're managing your rails app like that, you're running against the grain. Most rails apps should and, from what I know, are, being maintained at or near the latest stable version (currently 3.2.9). It's very much against rails best practise not to keep up to date, IMO.
Any fast-evolving framework is a bit of a moving target - see android and iOS as well, not to mention HTML5, jquery, apps written in anything fast-moving needs constant minor maintenance to keep up. That said, there's no reason a rails 1 app won't run today just like it always has.
One of the reasons rails can move so fast while avoiding bloat is its aggressive cutting of deprecated code. That has always been part of the rails way and I believe most rails devs are strongly in favour of this policy.
Great summary here, love the 3.2/4.0 side by side examples. I wondered why it hadn't mentioned the new background queue API though, only to find that's been pushed back out of 4.0 now. Just wanted to mention here incase anyone else hadn't seen that that has been taken out.
I didn't include queues, live streaming, and other features because unfortunately they are not available as a separate gems.
I tried to cover all the things that are possible now (via gems or simple code change).
Maybe in a future post I'll cover all the new things in Rails 4. But as it's still on development I prefer to wait until a beta or release candidate.
Awesome! I've seen a lot of little coverage on some of these topics but this is about as comprehensive as I think we'll find without any sort of release notes.
http://blog.remarkablelabs.com/2012/12/what-s-new-in-active-...
The official edgenotes has sections for all the Active components:
http://edgeguides.rubyonrails.org/4_0_release_notes.html