_Please_ give the RC a try, and file any issues you have on the tracker: https://github.com/rails/rails/issues?state=open There's nothing more frustrating as a maintainer than getting regression reports the day after you release when you've done two or three RC releases. :(
I'd be happy to answer any questions you have about the release either here or over email, as well.
I noticed that mperham mentioned on Twitter that he had 250+ bugs his test-suite after upgrading, and I am sure he and his team have better and more elaborate tests than me.
I personally have reviewed (but am not getting a cut of) http://www.upgradingtorails4.com/ and it's pretty good.
This was the smoothest major upgrade yet, with very helpful deprecation notices. Thanks for all the hard work.
The errors were I think caused by a change in the separation of the tests so database state was leaking between them causing failures but I haven't investigated deeply.
In these sorts of situations I never know whether it is best to 'bundle update' everything and have less information about the source of any problems or just to 'bundle update rails' and not receive the compatibility fixes straight away. How do others do this?
[Edited to add detailed version information and last paragraph].
Generally, I do this:
1) update everything, run `rake rails:update`, and run the tests. Hope this works. If not, figure out if the error is mine or a gem's.
2) If it's a gem's, try to lock it to the exact version I was using and repeat 1).
3) If that doesn't work due to version issues, investigate if the gem has some sort of preview support for rails 4.
4) if not, either send a pull request or an issue.
I think this is one of the biggest advantages of Travis' uptake in the Ruby world, actually: it's really easy to test your gem against Rails master and put it in allow_failures, which means you can know if your gem is compatible, and occasionally show when a new commit introduces an incompatibility.
If you find any gems that don't work, please ping me and I'll investigate and send PRs; this is one of the advantages of my employer (Jumpstart Lab) paying for OSS work. The whole Ruby world wins. :)
1) You take the commit referenced, like this: https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...
2) Right below the title, GitHub shows you which branches the commit is in. As you can see with that commit (the one that caused the problem), it's only in 3-2-stable. Therefore, not being in master, it wasn't ever in Rails 4, only in Rails 3.2.
Since this was a security issue, it's possible that the commit was different for Rails 4. So we load up the page for the referenced CVE (cve-2013-1854): http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1854
That page links to the announcement email: https://groups.google.com/group/ruby-security-ann/msg/34e0d7...
The announcement email discusses which versions were affected:
> Versions Affected: 3.2.x, 3.1.x, 2.3.x
But, since Rails 4 wasn't yet released, it wouldn't be there.
To be 100% sure, you can grab a copy of the source, and grep the git log for the CVE number. That brings up this commit: https://github.com/rails/rails/commit/2392535f4085d88186097e...
This commit is in master and v4.0.0rc1, as GitHub shows.
I am not mega super updated on the status of this issue, as I'm not on the security team, but given that it's still open and marked as 'regression,' I would not be sure that this was fixed.
That said, this particular bug is a complex interaction between components, and people haven't mentioned if it affects master or not. Therefore it's possible that even though the fix didn't make it into 3-2-stable yet, it may not have affected master.
So, at the end of all that, I guess the answer is "I'm not 100% sure, I'd ping tenderlove," but I hope that helps you identify which commits have made it into which releases in the future.
4.0.0.beta1 works fine on Heroku but I keep running into ActiveRecord problem after upgrading to 4.0.0.rc1.
I am wading through my Gemfile (over 200 gems counting direct and indirect dependencies) at the moment trying to give the RC a shot, but it's going to be difficult to justify spending much more time on it, unfortunately.
I'm currently fighting with redis-rails in particular, as bundler doesn't seem to be seeing the dependency change in a nested gem.
PS: I am the postgres_ext maintainer
I did some work on this today, would you mind sending me an email so we can discuss it? firstname.lastname@example.org
I had a look at it and got through a bit of re-working some of the changes (indexes etc), but got pretty quickly out of my depth of understanding around the inner workings of ActiveRecord.
If you need any help with the sample application please shoot me a message! Would be glad to pitch in some time.
I actually would love to see a comprehensive list, obviously can't all fit in this short release post!
In fact, Rails 4 is so extracted from David's working knowledge that some people feel it's _too specific_, hence the whole "Omakase" thing a few months back.
(I'd also note that your two sides aren't actually opposed: if you pull things out from 'working knowledge,' then you obviously think that they're the best. Both conditions can absolutely be true.)
Can anyone explain or provide a cite to more on this? What the intention is here, what one is supposed to do with gems only used in asset compilation but not needed in actual production app environment?
1) Sprockets integration was totally re-written, with huge performance benefits. It's now sprockets-rails.
2) Before, to precompile, you did this:
bundle exec rake assets:precompile
RAILS_ENV=production bundle exec rake assets:precompile
(Also, if when migrating an app from 3 to 4 you need to manually add 'sprockets-rails' to your Gemfile, should be mentioned in migration guide)
It seems unfortunate to me that all those gems involved only in asset compiling now need to be in every environment -- meaning they need to actually be loaded and 'require'd in your production running app, even though assets have already been compiled. Hopefully that change to requirements was needed to reap some worthwhile benefit, it's still pretty sketchy to me why the sprockets integration improvements led to this change.
> it's still pretty sketchy to me why the sprockets integration improvements led to this change.
Sprockets is one of the parts of Rails I know least about, so yeah, I'm not sure why this decision was made. But explaining it somewhere for posterity is a good thing, absolutely.
There have been enough performance and functionality related issues in 3.2.13 that I was hoping to see at 3.2.14.
Tl;dr: after 4.0 is released, no. But bugfixes have been merged into 3-2-stable that there should be a 3.2.14 before the security-only releases start.
Another big one is the 'not deprecating something in z releases (of x.y.z)' policy, which should help too.
Remember, Rails does not follow SemVer, so if you're expecting interface compatibility to line up with it exactly, you're gonna have a bad time. If we _had_ followed SemVer, you wouldn't see all those comments upthread about how this was 'the smoothest major upgrade ever', since in SemVer 3 -> 4 would mean no compatibility.
Check the upgrading guide for a reasonable Tl;dr, I'm excited about strong_parameters and HTTP PATCH, personally.
I personally have had good luck upgrading small apps very easily from 3.2->4.0. The main thing I've run into with larger apps is going from attr_accessible->strong_params, which I realize I could do simply by adding the gem, but I'd rather go whole hog on it.
Rails 4 may be stable, but there are a thousand gems to still be brought up to speed. It very well may get easier later.