My book Merb in Action, is available now in Early Access from Manning Publications

Monday, January 28, 2008

The last of the Merb 0.5.x line

Just a few minutes ago I tagged and released Merb 0.5.3 “Inexperienced With Girls”, and it should be on the gem servers soon. This is (hopefully) the last of the 0.5.x releases of Merb. It’s the last unless something horrible is wrong with it.

Starting …. now .... we’re really focusing on the 0.9 code, which has some significant changes in terms of process. First and foremost, we’re using git to manage the development, instead of Subversion. Also, we’re splitting the codebase up into merb-core and merb-more, to balance that delicate line of “super small and focused yet feature-rich”.

If you’d like to see where things are headed, here’s the repos on GitHub:

One of the super cool things about GitHub is that it makes hosting a fork of a project trivial. One of the super cool things about git is that it makes cherry-picking changesets from one tree to another really easy. Combine those two things, and you get a completely different development style than with central-repo projects.

Right now, my experimental merb-core is the same as upstream, but I’ll be doing stuff in there that may or may not be ready for official merb. I’ll let you know if there’s anything interesting in there.

The release of 0.9 is planned for February 8th, IIRC. There’s a lot to do, but we’ve made a lot of progress. My next task is to make sure the preliminary 0.9 upgrade checklist that wycats made is all that’s needed (it can’t be that easy, can it?) and then go through merb-core and make sure all the HTTP compliance and support is good.

Tags:   

Comments

Leave a response

  1. YaroslavJanuary 31, 2008 @ 02:52 PM

    Awesome release name.

  2. Dan KubbFebruary 02, 2008 @ 11:35 AM

    Mike, a good resource to check merb against for its HTTP compliance is the following flow chart:

    http://thoughtpad.net/alan-dean/http-headers-status.html

    It gives alot of information about how requests should be handled, and what status codes to return in certain situations. Its missing a few things, like returning 422 Unprocessable Entity when a PUT or POST request body is well formed, but contains invalid information (Fielding commented in rest-discuss this was the best status to return in this case); otherwise its probably one of the best resources aside from RFC 2616.

  3. MichaelFebruary 02, 2008 @ 05:50 PM

    Dan, that’s an excellent resource. Thanks for that.