This is a huge step forward to a big release! I myself built a little app with the RC, Ruby 2.0, and deployed it to Heroku yesterday, and that whole stack works just fine.
_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.
Sorry for a potential stupid question: Is there an upgrade guide somewhere?
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.
As mentioned below, there is that official upgrade guide. It is not comprehensive, as mentioned in the post. Should get you going, though. We'll be continuing to work on it now that there's an RC out.
I had many failures when I just updated rails (from an edge version a couple of weeks old) to rc1. When I did a full bundle update it picked up the latest rspec-rails (2.13.1 instead of 2.13.0) and everything passed again.
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].
How do the major gems play with this RC? Namely Devise, CanCan, etc.? I was going to play with the beta, but I think I saw some potential integration issues with Devise and I decided it wasn't worth the trouble.
Most of the biggest ones have been working for a while, or have a branch where they're working in support.
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. :)
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.
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.
The issue I keep running into when testing the RCs with larger apps is the number of gems that have strict dependencies on older versions of activesupport, etc.
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.
Why not post your whole gemfile as a gist? People in the HN community could definitely go through and start to check some of the dependencies for you :)
What features are you using postgres_ext for? A lot of the ActiveRecord datatypes support is handled by Rails 4.0 (arrays, uuid, ranges, inet/cidr and macaddr are in Rails 4.0). I want to submit some pull requests to Arel to add support for some of the datatype operators
In the case of postgres_ext you should actually check to make sure the functionality you need isn't already in Rails 4. Dan McClain extracted much of what he did and got it pulled in.
schema_plus (https://github.com/lomba/schema_plus) is having issues with ActiveRecord changes (API changes, methods not existing any more that they remove/overwrite etc).
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.
Thanks for mentioning this. You're right that the beta book has been out for a while, and I've tried updating the Rails Tutorial for the release candidate as well, but the new RC breaks tons of tests in the sample application. I probably won't have time to figure out the cause of the breakage until after RailsConf is over, but I'll plan to get to this ASAP next week.
Obviously, these lists aren't comprehensive: I have commit to Rails, am helping to write a book on Rails 4 [1], and it's not listed, either. ;) AWDWR is actually tested as part of each release,[2] so it obviously gets a big shout-out.
It's a little farther behind the others, Ryan had updated it for Rails 3.2, and I'm updating it for 4, and my editor and I are going over the first half of the book's updates now. AWDWR is already 100% updated (and I think CRA is too), so it makes sense that mine didn't get mentioned; it's hard to both work on Rails and work on writing a book on Rails.
I remember there was a time when rails releases meant extraction of working knowledge into the framework. Now it looks like they are just choosing to support frameworks which they think are the best.
Most of the features added to Rails 4 came directly out of David's work on making Basecamp Next fast.
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.)
> Rails 4.0 removed the assets group from Gemfile. You'd need to remove that line from your Gemfile when upgrading.
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?
I'm not sure of the details of what changed about this, but basically, it was that you did need assets in all environments anyway, so the group is no longer needed.
Thanks for more details -- is this documented anywhere yet? If not, it might be good to add to the "docs needed" checklist.
(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.
I am not 100% sure. I'll talk to the people in charge of the asset pipeline and get it in there.
> 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.
Wow, just one version beyond the most current one, this sucks so much, especially combined with the rather careless attitude about backwards compatibilty...
We've made significant steps towards not having a 'careless attitude,' that blog post being one of them. Now the exact policy is spelled out.
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.
I would do it now; it's not going to get easier later.
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.
If you're coming from 3.1 or 3.2, I say go for it. I have brought a couple applications from 3.2 -> 4.0rc and both had specs fully passing within 30 minutes of the switch. git checkout -b rails4, it won't hurt to try.
_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.