14. Switching to Ruby 1.9
I've been developing for Ruby 1.9 exclusively since December. It does unicode right, it does block parameters and local scope right, and it's fast. It's also been stable for six months. What is everyone waiting for?
They're waiting for the gems. Quite a few of them are broken in 1.9, yet they tend to be fairly easy to fix. Once you know how to deal with a few common problems, you can migrate a typical small gem in an hour or two. I've done a bunch and put them on my Github.I've noticed that many people are doing the same thing: making Github forks of Rubyforge projects just to migrate to 1.9. Unfortunately, figuring out which ones, if any, are usable can take some detective work and experimentation. Most developers don't go to the trouble of submitting patches back to Rubyforge, and often can't anyway because the original project has been abandoned.
We have all the manpower we need to make the switch, we just need to get coordinated.
This site has been a big help, but the idea can be taken further. We need this site, or one like it, to implement the following features:
- Provide a quick way to fork Rubyforge projects on Github
- Track all existing forks and their networks on Github
- Democratically choose the most mature fork using some sort of voting/rating system
- Modify Rubygems to treat that fork as canonical and pull it from Github, when running under 1.9
Ok, this plan is half baked at the moment, but I'm confident that the ideal solution is along these lines. Rip might also be involved somehow. The key is decentralizing gem maintenance so that active developers can take control of neglected projects, and that means decoupling from Rubyforge.
Whatever the plan is, the community needs to get on the same page, because right now there is no plan at all.
Comments