Merb 1.0 RC5
As you might have noticed, we’ve been pushing a lot of Release Candidates out the door. The reason is that we want to make sure 1.0 is really ready for showtime!
We are also getting a lot of bug reports that help us focusing on the main issues. Today RC5 was pushed to a RubyForge mirror close to you and here is a report from Yehuda Katz, Merb lead developer.
This is the final RC before we ship 1.0 final at RubyConf. Here is a really quick rundown of the bugfixes and improvement added to this release:
- Webrat integration out of the box. (see example)
- Improved Merb bundling
- spec view helpers now use nokogiri (with rexml as fallback )
- new have_selector spec helper using CSS3 compatible selector.
- The entire Merb spec suite now runs correctly on JRuby & Windows.
- Once again improved jRuby support.
In other news, we setup a nightly gem server so people who want to be on Edge don’t have to deal with git and we call also test gem releases before pushing to RubyForge. More about that coming up during RubyConf.
Talking about RubyConf, Yehuda and I will be in Orlando enjoying a good Ruby meetup. Come and chat with us if you are interested in starting using Merb, or if you have been using Merb. Also, please come and see us if you hate Merb and care tell us why. We’re looking forward to meet you all.
10 Responses
Did you guys switch to nokogiri for a performance boost? Cause, you know, _why has already beaten it with hpricot. Just asking,
Posted on November 3rd, 2008 at 10:18 pm
@srdjan good question, the short answer is “not only”.
Sure the speed bump is nice, and hpricot got better today (followed by Nokogiri which caught up).
However bugs and inconsistencies in hpricot plus the need for a XPath => CSS converter pushed us to look at Nokogiri. (Doesn’t mean you shouldn’t use hpricot at all)
Also, note that nokogiri is only needed in development not production.
Posted on November 3rd, 2008 at 10:48 pm
“This is the final RC”
Very optimistic! Unfortunately, .14 is already on the edge gem server and there are many outstanding bugs in Lighthouse. Maybe after 3 or 4 more RCs?
Posted on November 4th, 2008 at 3:43 pm
Ok i did this > http://gist.github.com/22251
and it seems to work - is this the recommended way to go about it?
My goal was to have a blank merb project with everything bundled
Posted on November 4th, 2008 at 3:51 pm
[...] Merb 1.0 is almost here and I’ve finally got it to work out of the box! [...]
Posted on November 4th, 2008 at 4:03 pm
The nightly gem server for edge is a great idea. It’s ok to have a few more RC’s I believe, these are there for a reason
Keep up the good work.
– Thibaut
Posted on November 5th, 2008 at 6:15 am
@geoffrey booo :p
O man of little faith, why are you in doubt? Ok we still have some issues on Edge but I wouldn’t call them major, 1.0 final probably won’t be perfect but it’s a stake in the ground and we won’t wait 6 months to release a 1.0.x
Since you’re coming to RubyConf, let’s have a chat and help us decide if 1.0 will be ready by then or not.
- Matt
Posted on November 5th, 2008 at 11:09 am
for a framework that is supposed to simplify things, merb sure lacks quality control. so much is focused on the 20% that Rails doesn’t do, what about the 80% that Rails does do? this framework feels hacked together. it’s becoming like J2EE, plug this in, plug that in, dependency this, dependency that, wait something is better this week, plug that in. you guys have brought DLL and Classloader hell to Ruby.
Posted on November 6th, 2008 at 1:21 pm
@mike the goal with Merb is to make both the 80% and 20% possible. This turns out to be a very hard problem, and we’ve been working for almost a year on 0.9. To ameliorate the “dependency this dependency that” problem, we released tge merb stack, which gets installed with gem install merb. If you use the stack, you don’t need to worry about “plug this in plug that in”, everything works out of the box.
We’ve been working hard on bundling, which lets you create a version of your app that will run on any machine, including a remote machine with just ruby and rubygems installed (or any configuration of gems). Again, this turns out to be a pretty hard problem, and Rubygems (esp. 1.2) fights us every step of the way.
We haven’t brought classloading and dll hell to Ruby, we’ve exposed some underlying issues with the Rubygems implementation that doesn’t happen if you don’t support code reuse and modularity to the extent that we do. We’re working with the rubygems guys to improve this for the future, and have some ideas that we can do in Merb itself to further reduce the potential for problems.
Thanks for your concern.
Posted on November 6th, 2008 at 1:33 pm
[...] The Merbist just announced that Merb 1.0 RC5 (Release Candidate 5) is now out: “This is the final RC before we ship 1.0 final at RubyConf. Here is a really quick rundown of the bugfixes and improvement added to this release: [...]
Posted on November 8th, 2008 at 1:54 pm
Add A Comment