So some of you may have seen the news about Gemcutter.org changing its name to RubyGems.org and becoming the new default gem repository for the Ruby community. I’m not completely clear yet on all the pros and cons of this move, but I do have to admit that the new site is pretty to look at. As a maintainer, I like the idea of being able to just type “gem push fxruby” (or whatever the command syntax is) and being done with it. So I think this will probably turn out to be a good thing.

Buried a few paragraphs down in the news, however, is this tidbit:

So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away.

In the comments, I asked for clarification on exactly what RubyForge services will be going away, and Tom Copeland’s reply seems to indicate (to me) that the answer is “everything”:

… We’re putting together a schedule for standing down (or making read-only) various bits of RubyForge. The thing is that now there are much better options for hosting code/forums/lists/files/etc, so that stuff is going to be retired. I think back in 2003 it made sense for the Ruby community to have a dedicated site for hosting that stuff. Now I don’t think it does… I think GitHub/Google Code/SourceForge can all do a better job at that, and Ruby Central doesn’t have to expend resources/time/money supporting functionality that others are doing better.

This is troubling to me since several FXRuby-related services (such as the web page hosting, bug tracker, and mailing lists) are handled by RubyForge, and have been for a long time now. For me, it’s not merely a question of, say, finding a new place to host the mailing lists. It’s also making a decision about what to do with the archives, and dealing with all of the non-readers who will go out their way to try to subscribe to the old lists even when they’re clearly marked as inactive and then send e-mails to me to ask why that’s so. But I know that Tom and company are sensitive to these concerns, and we’ll figure out a way to make the transition work as painlessly as possible, so I’m going to try not to be a grumpy old man about it.

So in the meantime, I’m beginning to consider what my post-RubyForge options are. Setting up a dedicated Redmine installation, as Jim Weirich has done for his projects, is an attractive option as it provides one-stop shopping (and I’ve had some experience with setting up Redmine for other projects already). Another option is to go with different sites targeted at the different services, like entp’s Lighthouse for bug tracking, maybe Google Groups for the mailing list hosting, and maybe piggybacking the static web site content off of my personal web site somehow (ugh). What about you, dear reader? If you’re hosting one of the 8,500 projects at RubyForge, what plans are you contemplating for RubyForge’s looming retirement?

A long while has passed since the last release of FXRuby (in March 2009) and a couple of new platforms have appeared on the Ruby scene in the meantime. This post provides a brief status update on how support for those platforms is coming along.

One of those platforms is the new MinGW-based Ruby installer for Windows, which is quickly approaching its first release candidate. This is a really exciting development and while it’s not quite yet the official Ruby distribution on Windows, I don’t think that day is far off.

I actually quietly released a MinGW-compatible gem for FXRuby 1.6.19 a month or so ago, but there’s a little problem with it, which is that it’s only compatible with Ruby 1.8.6. If you’re running the MinGW build of Ruby 1.9.1, this gem isn’t going to work for you. That’s not a problem in and of itself, but it is a problem because the RubyGems installation process has no built-in smarts to distinguish between gems that only work with one Ruby version or another. Before someone jumps on that: Yes, I’m aware of the requiredrubyversion attribute for the gem specification. What I mean is, there’s no way to say, “I want to install the FXRuby gem for my platform, but make sure you get the one that was compiled for Ruby 1.9.1 and not the one compiled for Ruby 1.8.6.” The requiredrubyversion attribute seems to only be used to prevent you from installing an incompatible gem–it’s not something that the gems are indexed on.

The recommendation from Luis Lavena of the RubyInstaller project is to build what he calls a “fat” gem (as described here and here), one that includes multiple builds of FXRuby and that selects the “right” one at load time. This will naturally increase the gem’s size, but hey, disk space is cheap and it’s a proven solution to the problem. So I’m looking into this approach now and hope to incorporate it into my build process soon.

Another new platform is Mac OS 10.6 (aka Snow Leopard). For an operating system that’s just a little over a month old, you’d be surprised at how many people are already looking for an FXRuby gem for Snow Leopard. (Well, maybe I shouldn’t be surprised, given the Mac love in the Ruby community). This has been a little tricky because some of the tricks that I’d used in the past to build universal binaries on OS 10.5 (Leopard) didn’t work quite the same way under 10.6, but I think I’ve just solved that. If you’d like to help me test this, you can download a pre-release version of that gem here. Note that this is intended for use that the Ruby 1.8.7 that comes pre-installed with Snow Leopard. If you’ve built your own Ruby (as many folks do), this might work for you too, but if it does that’s just a nice bonus.

Once I’ve resolved the problems involved in supporting these two platforms, I’m planning to release FXRuby version 1.6.20. There won’t be that many functional improvements for those of you already using FXRuby 1.6.19, but it will help to prove out the new build process and re-stabilize things for future releases. I’ve also been doing a lot of work behind the scenes recently (since the move to GitHub) to make it easier for people to hack on FXRuby and contribute code back to the project, but that’s a subject for another post.