--- date: "2004-08-25T14:44:12Z" title: Thoughts on RubyForge/RubyGems ---

In order to post a RubyGem at the moment, you have to create an account on RubyForge, then create a project, then upload the gem. RubyForge gives the same things that SourceForge does; a web site, a CVS repository, a file area, forums, mailing lists, kitchen sink, etc. Pros: RubyForge is prettier, simpler, and more stable than SourceForge (although I've seen Windows 95 machines that are more stable than SourceForge, so that's not saying much). Also RubyForge doesn't have 8 gadzillion dead projects on it, so it's significantly faster than SourceForge. Cons: No automated interface (XML-RPC, SOAP, email, smoke signals, etc... Freshmeat has an XML-RPC interface, so this isn't an unrealistic request), no quick way of creating a minimalist project (for example, a project that just classifies itself in the Trove and posts a gem..ie, what I want to do), and no integration with RAA or Freshmeat.

I want to elaborate on the last one a bit, because that's a problem with both RubyForge and RubyGems. Let's look at the steps I take when I release the latest version of a Ruby binding:

  1. Sanity check, make sure the thing still compiles
  2. Run whatever testing script I have written, make sure I haven't broken anything crucial
  3. Update the documentation (README, TODO, BUGS, etc)
  4. Tag the release in CVS. If I'm incrementing the major or minor number, then I create a new branch as well.
  5. Export the specified tag to anohter directory (I've got one called releases/ on my workstation).
  6. Double-check everything again to make sure things are where they should be (I catch a lot of stupid mistakes here, by the way).
  7. Run RDoc to generate the developer documentation.
  8. Tar the release up.
  9. Sign the tarball with GnuPG (everyone should be doing this; shame on you if you aren't).
  10. Upload the tarball, signature, ChangeLog, and API documentation to Pablotron.
  11. Update the links, version number, and possibly the blurb on the software page.
  12. Post an entry to the front page briefly describing the release.
  13. Update the binding's entry on RAA.
  14. Update the entry on Freshmeat.
  15. Post a short message to ruby-talk.

If I'm using creating a gem, then we have to add the following items to the list:

Well, if there was some interaction between RubyForge, RAA, and Freshmeat, a lot of redundant steps could be eliminated. I'm picking on RubyForge here because it's the new kid on the block; Freshmeat has been around since the dawn of time, and RAA has Ruby's semi-answer to Perl's CPAN since I started using Ruby. For example, let's say RubyForge had an XML-RPC interface, and it could communicate with RAA (via some RPC interface) and Freshmeat. Now write a script that creates a gem and does the necessary updates to my personal page, then connects to RubyForge via XML-RPC and uploads my tarball, gem, tarball signature, and gem signature, which are then automagically propogated to both Freshmeat and the RAA.

In short, an automated update interface combined with the ability to interact with the other existing software indices would allow me to eliminate half of the steps on my software release checklist and make RubyForge incredibly useful to developers, even if they don't need web hosting, a mailing list, or a CVS repository.