Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 4.0: Release Candidate 1 released

weblog.rubyonrails.org

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Rails 4.0: Release Candidate 1 released

#51

Post by steveklabnik »

stiff wrote: post #44
steveklabnik wrote: post #39

Earlier quoted context omitted.

Here's the maintenance policy: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f... 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.

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.

Re: Rails 4.0: Release Candidate 1 released

#52

Post by jrochkind1 »

steveklabnik wrote: post #48
jrochkind1 wrote: post #46

> 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?

Two things: 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 Now, you do this: RAILS_ENV=production bundle exec rake assets:precompile 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 lo…

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.

Re: Rails 4.0: Release Candidate 1 released

#53

Post by steveklabnik »

mpd wrote: post #16
steveklabnik wrote: post #14

Earlier quoted context omitted.

Can you tell me which gems you're having problems with? I'll send a bunch of pull requests this evening.

Sure - so far I've had to update postgres_ext, rails_autolink, redis-rails (part of redis-store package), and marginalia. I'm currently fighting with redis-rails in particular, as bundler doesn't seem to be seeing the dependency change in a nested gem.

Hey mpd,

I did some work on this today, would you mind sending me an email so we can discuss it? steve@steveklabnik.com

Re: Rails 4.0: Release Candidate 1 released

#54

Post by steveklabnik »

shimms wrote: post #33
steveklabnik wrote: post #14

Earlier quoted context omitted.

Can you tell me which gems you're having problems with? I'll send a bunch of pull requests this evening.

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.

AR is my least-understood part of Rails, but I'll give it a look.

Re: Rails 4.0: Release Candidate 1 released

#55

Post by steveklabnik »

jrochkind1 wrote: post #52
steveklabnik wrote: post #48

Earlier quoted context omitted.

Two things: 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 Now, you do this: RAILS_ENV=production bundle exec rake assets:precompile 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 lo…

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…

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.

Re: Rails 4.0: Release Candidate 1 released

#56

Post by zachgersh »

mhartl wrote: post #22
zachgersh wrote: post #2

Weird that the skipped out on Hartl Tutorial in their announcement, it's actually been in Beta for awhile: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book?ve...

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.

Love the book and so happy it is available (I am sure I speak for many others).

If you need any help with the sample application please shoot me a message! Would be glad to pitch in some time.

Re: Rails 4.0: Release Candidate 1 released

#57

Post by phsr »

mpd wrote: post #16
steveklabnik wrote: post #14

Earlier quoted context omitted.

Can you tell me which gems you're having problems with? I'll send a bunch of pull requests this evening.

Sure - so far I've had to update postgres_ext, rails_autolink, redis-rails (part of redis-store package), and marginalia. I'm currently fighting with redis-rails in particular, as bundler doesn't seem to be seeing the dependency change in a nested gem.

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

PS: I am the postgres_ext maintainer

Re: Rails 4.0: Release Candidate 1 released

#58

Post by bcardarella »

mpd wrote: post #16
steveklabnik wrote: post #14

Earlier quoted context omitted.

Can you tell me which gems you're having problems with? I'll send a bunch of pull requests this evening.

Sure - so far I've had to update postgres_ext, rails_autolink, redis-rails (part of redis-store package), and marginalia. I'm currently fighting with redis-rails in particular, as bundler doesn't seem to be seeing the dependency change in a nested gem.

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.
Post reply on HN