Rails premieres on GitHub

GitHub has now officially launched and Rails is right there at the premiere. The Rails repository now lives at rails/rails and you can check it out with:

git clone git://github.com/rails/rails.git

If you don’t have git, or don’t enjoy running it on your platform, you need not fear. We’ve set up an automated task to produce a zip file of Rails Edge that’ll be kept up to date all the time: http://dev.rubyonrails.org/archives/rails_edge.zip. This is also what we’ve made the new rake rails:freeze:edge use.

This also means that development on the Subversion repository has stopped and will no longer be kept up to date. We’ll keep the Subversion repository around for some time for people to transition off svn:externals, though. But if you want the latest edge, you’ll have to use either git or the new zip files.

We’ll also soon go live with our new ticket management system, which will be running on a new version of Lighthouse. When that happens, the Trac installation will follow the Subversion repository into legacy. We’ll still keep it around so we can work through all the patches and tickets that are there, but everything new will happen on the Lighthouse setup.

We hope you’ll enjoy this upgrade to the Rails collaboration infrastructure. We’re really looking forward to the onslaught of marvelous patches that the Git lords have promised us will flow from the mountain now.

Why Git won't mean Rails snubs Windows

There seem to be some confusion over what the core development of Rails on Git will mean to Windows users. The simple answer is: Absolutely nothing. But let me give you a slightly more involved answer:

  • rake rails:freeze:edge will still work. We’ll make it use either zip or tar.gz files. It’ll actually be even better as it won’t even require a SCM to work.
  • Tickets will still accept regular patches that you can create with any diff tool.

So this will mean no difference to users of Rails and it’ll mean no difference to developers of Rails. What it will mean is that people who are interested in using Git (which again does come in a variety of flavors for Windows despite not being as well-supported as on nix) will get some value-added features in form of easier branching and the other Git goodies.

If you’re freaking out, calm down. Rails and the developers behind it have snubbed Windows far, far worse in the past :). The original release of the framework didn’t even run on Windows. This move to Git is not a snub.

Rails is moving from SVN to Git

We’ve been preparing for Rails to move the official source repository from Subversion to Git for some time now and it seems that it’ll happen over the next week or so. The premiere will happen alongside the official launch of Github.

The move will also mean that we’re going to be switching ticket tracking to Lighthouse. So now both our repository and ticket tracking will be powered by Rails applications, which is a nice bonus treat.

When the move happens, we’ll freeze the existing Subversion repository and the Trac installation. Both will live on for a long time to come, but will be entirely deprecated. This means that your existing svn:externals will not break, but if you want the latest edge, you’ll have to get it from the new git repository.

So now is a great time to learn more about Git in anticipation of this move. I recommend starting with the Git for SVN’ers crash course.

A taste of what's coming in Rails 2.1

Rails 2.1 is not far off the horizon and we’ve been adding a ton of extra deliciously nice goodies in preparation of its release lately. As always, the good Ryan Daigle has been keeping a watchful eye on the changelog and has been documenting some of the new features. The latest stars are:

Pratik joins core, retired members go alumni

We’re shaking up the Rails core group a bit. First, please welcome Pratik Naik as the newest member of the group.

He’s been doing great work all around the framework and has been spearheading both the documentation branch in git and a thorough cleanup of Action View internals. We’re really happy to hand him the commit keys to the repository.

Second, we’ve created the Rails core alumni for all the proud members of the core group who are no longer in the day-to-day improvement of the framework itself. All of the alumni are still busy working in the Ruby on Rails ecosystem, but either have their hands full with their business or has dedicated their open source time to other initiatives.

We’re incredibly grateful for all the works you guys have done for Ruby on Rails over the years. And you’re all welcome back in the active core group any time you decide. Thanks guys!

Finally, this means that the current active core group is about half its former size. We’d like to add a few more to that, so hopefully we can pick a few more people who’ve been doing varied work on the framework for a sustained period of time soon.

Comparing Rails 2.0 to 1.2 for speed and memory

Hongli Lai has compared a dummy scaffold application from Rails 1.2 to Rails 2.0 and found the latter to be 30-50% faster. That’s great to see.

But what I think is even more interesting is the progress we’ve been making on performance optimizations for more substantial applications. Rails 2.0 made a lot of progress for applications with lots of assets and for ones with big routes.rb files. The forthcoming Rails 2.1 will move things forward even further.

UPDATE: Hongli also investigated memory consumption on 1.2 vs 2.0 and found 2.0 to be significantly slimmer. Nice!