Rails/master is now 4.0.0.beta
Posted by David December 20, 2011 @ 03:33 PM
The forthcoming 3.2.x release series will be the last branch of Rails that supports Ruby 1.8.7. There’s a new 3-2-stable branch in git to track the changes we need until 3.2.0 final is release and for managing point releases after that.
So for now you should stop floating on rails/master if your application is not compatible with Ruby 1.9.3. We have updated the version numbers to indicate this backwards incompatibility to be 4.0.0.beta. This doesn’t mean that 4.0 is anywhere close to being released, mind you. We’re simply doing this now because we’re dropping support for Ruby 1.8.7 in rails/master and people should know what’s up.
Major versions of Rails has been on about 2-year release cycle since 1.0 (released in 2005, followed by 2.0 in 2007, followed by 3.0 in 2010) and we intend to continue this pattern. The current internal target for Rails 4.0 is sometime in the Summer of 2012 — but we have blown every major release estimate in the past, so don’t bet your farm on it.
There’s not a lot of details about what we’re going to include in Rails 4.0 yet as the primary purpose for bumping the major version number is to drop Ruby 1.8.7 support. But unlike Rails 3.0, we intend for it to be a much smoother transition. The intention is not for this to be a REWRITE EVERYTHING release in the same way 3.0 was to some extent.
But we’re getting ahead of ourselves. First mission is to get Rails 3.2 out!
I enjoy how fast the Rails world moves, always keeps me on my toes.
I can’t wait to know what will be the big features of this new branch! :)
Would 4.0 be more along the lines of the Cinco discussion from earlier this year?
Is Rails going to follow the current trend toward more client-heavy apps (UI pushed to the client, server REST API endpoints)?
nm, Rails is a great REST server if you want to have an entirely JavaScript-based front end. See things like Jbuilder and Serializers for some of the ideas we’re playing with for 4.0.
But in general, there’s no drastic switch coming to the core of the framework for this.
Dropping support for a language interpreter that is still widely in use does not really qualify as a smooth transition to me. C extensions for 1.8.7 cannot be used in 1.9.x… Although it is a different pain, I think the transition to rails 4 will be as painful as the transition to rails 3.
I agree with Ewout. Hence why I’ve stuck with Windows 95 up til now.
ewout, you still have 6+ months for extensions to get up to date..
Also, I think most people have already or are already updating their apps to 1.9.x support.
Ben, thanks for being a dickhead. Happy holidays!
Oh, and to actually make the comment useful, many of us are still on 1.8.7 because it doesn’t segfault like 1.9.2 and is remarkably faster. No point in fixing what isn’t broken. But, maybe Ruby will stabilize by the time Rails 4 comes out.
Sorry Ben/mmriis, but ewout/Kevin are right I think. REE is still 40% faster for a large Rails app, although I’d love to be proven wrong (loads of threads on Google/Stackoverflow).
It’s going to be uncool to lose 40% for no gain on the Ruby side.. unless the Phusion guys can save the day and release 1.9.3 REE!
Whatever they do with copy-on-write and GC is just better.
mmriis,
I suspect the larger issue for a lot of people is upgrading an app cluster in-place. Even if it’s 1.9.2 compatible, upgrading > 5 servers to the newer version of Ruby with close-to-zero downtime is a large & risky undertaking, with little upside.
Did you guys consider and reject “alpha” instead of “beta”?
Losing REE’s copy on write would be a real shame, let’s hope the Phusion guys release a 1.9 compatible version before Rails 4 hits.
@Kevin You don’t like Windows 95?
@Kevin You don’t like Windows 95?
The Rails team cannot wait for every gem to be 100% 1.9 compatible. If some people still need 1.8 compatibility then they can continue to use Rails 3 even if Rails 4 is released.
Just name it to Rails 95! :)
@Tanguy
The same thing was said about the Rails 3 upgrade. However, given how easy it is to maintain backports of bug and security fixes in a dynamic language, hardly anyone actually does it. You basically have to run the latest Rails or maintain your own forks of everything.
sass integration seems to be horribly broken in this release right now. Curse you asset pipeline!!!
You know, as software matures and its community grows, there’s no shame in decelerating the release schedule. Keeping up a mindlessly linear schedule is not necessarily a virtue in itself, especially if it goes against the grain of developer productivity and happiness. I’d much rather be building stuff than endlessly dicking around with gem compatability and ruby version issues.
For SHAME. All haters here stuck with 1.8.7 seriously need to shut the fuck up. If you need/have/want to stick with legacy software that is your choice, but don’t drag the rest of the world down with you. MRI 1.9 is a lot faster than 1.8.7 and has tons of useful features and additions to the standard library, saving lots of development hours. As for the alledged pain of upgrading servers or clusters, well guess what? That is your JOB. DO IT and quit whining! Ruby 1.9 has been out for a long, long time.
joost,
My job is to add value for my customers, not to deal with Ruby segfaulting or needless server upgrades. Choosing to use something fast and stable shouldn’t be considered a mark of poor craftsmanship. I take it from your comments you haven’t actually managed a reasonably large app or cluster, otherwise you’d see you’re wrong on most accounts.
That aside, my choice to use 1.8.7 doesn’t hold you back from using 1.9.x. Supporting both is trivial in most cases, since Ruby is a dynamic language after all.
I should probably add that Rails 4 dropping 1.8.7 was well-communicated, so I’m not complaining about that. It’s just a shame is all.
If your upset about 1.8.7 being dropped because 1.9 isn’t ready for you, roll up your sleeves and get involved. Folding your arms and complaining is a lazy man’s excuse for not getting involved.
This is Open Source. Carve out some time each day and get involved.
There’s a solution if you’re not a fan of losing performance when going from Ruby 1.8 to Ruby 1.9 (which is only true in certain circumstance) – it’s called JRuby :-) JRuby is faster than all MRI releases, supports both 1.8 and 1.9 syntaxes, and is easily deployed.
Miles,
Your supposition is that 1.9 buys me something. Given that it doesn’t, why would I put any effort into it? I mean, I already have a Ruby that works wonderfully well.
And FWIW, I spend close to 30 hours a week on open source (all in my free time), so it’s a bit disingenuous to call me out for that. I can’t reasonably work on every project I use.
Peter,
Thanks for the suggestion. I’ve actually been trying to cut over to JRuby. I’m almost there, but a lack of yajl port is my current stumbling block. I’m hoping to bang something out with Jackson though.
@Kevin: So why don’t you add value to your customers with Rails 3.2? Nobody forces you to upgrade ;-)
Btw: Ruby 1.8.7 itself will just get security updates from June next year and will die in June 2013 (http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/). That’s about the same time, Rails 3.1 will be unsupported.
It’s perfectly reasonable for Rails move forwards.
Any plan to suppor Event-driven Non-blocking I/O ? For example integrate Eventmachine by default.
@Johnson have you not heard of fibur?!?
First, I did not mean to start a rant here. Rails is open source software and we appreciate all the work that is being done on it.
However, the rails community uses a very broad definition of the term “legacy software”. Moving forward is cool, but moving too fast means narrowing the community to only those that have enough time and money to keep upgrading their applications.
Sometimes you have to make a radical change for things to become better. Doing that two releases in a row will segregate the community in my opinion.
I’m very glad that Rails will finally push 1.8.7 out of the way. Ruby’s main driving force in the western world is Rails (for better or worse) – as a developer community we cannot continue to be blind to Encodings, threading and other common 1.8.7 problems. PHP, Perl and the likes all struggle with these principles, and though change is never easy, the 4.0 requirement bump is a nice move.
And arguably a better move than Coffee Script or the Asset Pipeline (sass is now woefully bad)
@DHH,
Thanks for the additional information.
For DHH or anybody, if I’m going for the JS front end, are there any configuration changes I should make to Rails to improve performance, exclude unnecessary components and so on?
Like when I first generate the app?
Rails moves fast, but ActiveRecord still sucks.
Sequel FTW.
This is great .
Seriously havent been accustomed to all new features of Rails3, and we are looking for Rails 4 launch . Amazing.
Hopeful to see some dynamic features in Rails4 .
However, I wish we could make RAILS cross platform friendly.
Kudos !!!
Rails 4.0! I just love this :)
Ruby 1.8.7 is faster and doesn’t segfault you say? Cool story. You can keep using it as long as you like… with Rails < 4.0. Moving right along…
It´s nice to push Ruby forward and Rails popular as it is, will be of great help!
I think there should be more work on improving performance of Rails.
Guys. Just because Ruby 1.8.7 won’t be oficially supported, doesn’t mean Rails 4.x won’t work with it at all. It just won’t be a concern for the core team, that’s all. But if anyone would like to maintain an up-to-date fork of “rails 4.0 with 1.8.7 compatibility changes”, then why not?
Won’t make a lot of sense, though, as all the other 4.0 gems will probably also drop official support for 1.8.7. Time to switch!
This means with version 4.0 that Rails will no longer work out of the box on the Mac.
So, how bout it Apple? Wanna move to Ruby 1.9 already?
Who does use default (and old) Ruby 1.8.7 from MacOS?
RVM for the rescue!
Also, with Ruby 1.9.3, a lot of problems have been solved and we also get a huge speed gain on requires (less startup time).
Who says the opposite is just lazy to test.
I can’t even imagine not working with 1.9.x… and you get system threads/fiber for free.
What?? I cant believe there are even people here advocating that rails 4 should support 1.8.7 . If you use 1.8.7, then surely you can use rails 3, and not 4. Put the pressure on your framework vendors that dont support ruby 1.9, and dont drag the rails framework down because you have some prehistoric component of your code that wond work with 1.9.
We should really start to imporove scalability, performance and reliability of Rails!
We should also have to look at speed improvement and efmake ficiency (in terms of idle cpu cycle)in rails app. I request ruby developer to documentation on how to they have written ruby using c as it help in better understanding ruby which ultimately increase performance.
haters gonna hate
meanwhile people are slowly adopting ruby 1.9 and that’s good
with rails 4 coming out adoption will be even faster and that’s even better
Ruby 1.8.7 has the benefit of REE and the additional possibilities of Kiji.
Although 1.9 has exciting features like fibers, it is currently not acceptable due to its lame GC and memory requirements. I don’t think Phusion is planning anything with 1.9. Perhaps 1.9.4 will add copy on write. Perhaps it is time to switch to JRuby.
and one more thing.
For all the people complaining about segfaults in 1.9, it is not like 1.8.7 is segfault free. It has numerous segfaults and bug. For example the infamous bundler error “not in gzip format”. Some these have been fixed in REE.
Investors love Ruby on Rails.
One of the great things that made me a rails lover is,every new version of rails comes up with many beautiful things,which really reduces the pain of developer and also things that make the love double on this technology. Hats off to the rails community….
Welcome you Rails 4.x ! Thanks to the core team.