in which is recounted a tale of versions

There are a number of ways to solve the problem of distributing prerelease gems in Ruby. Indicating a version is a prerelease in the documentation alone won't cut it; it's bound to sneak on to a production system and be forgotten about. Some projects simply don't bump the version until it's final, but this means if you try out a prerelease version it will replace an existing stable one, which is bad news. Up until recently, Rails marked them by counting backwards from the target, so the prerelease for 2.1.0 was 2.0.999. This ends up being better, but it still breaks when another gem says it depends on any version of Rails in the 2.0 series since 2.0.999 should be in the 2.1 series and introduces changes that will break gems expecting 2.0. Now Rails has changed strategies, saying that 2.1.0 is actually a prerelease, and that the first stable version would be 2.1.1. This is safer in terms of dependencies, but much more confusing to users; they expect 2.1.0 to be the actual release.

So during RubyConf, I worked with Alex Vollmer and Josh Susser to fix the problem from within RubyGems. The idea was that you should be able to mark a given version as a prerelease, and it wouldn't be downloaded unless someone specifically asked to include prereleases. This way in-development gems can get served without projects needing to run their own gem servers or rely on github; everything can be done through RubyForge. It also has the advantage of being much more clear; there's no need for each project to have their own policy on the matter. I've finally finished committing the new functionality to RubyGems trunk, so if you're interested in creating a prerelease gem, I'd encourage you to grab a copy of trunk and try it out:

$ svn co svn://rubyforge.org/var/svn/rubygems/trunk rubygems

$ cd rubygems && sudo ruby setup.rb

Once it's installed, try releasing a gem (using hoe or whatever) with a version with a segment that contains letters, and it will be considered prerelease. 2.2.0.rc1 or 1.6.5.a would work. The numeric segments are sorted as you'd expect, and the alphanumeric segments are sorted with String#sort, but prereleases always sort lower than releases within a version series. So 2.2.0 would be higher than 2.2.0.rc1 though they'd both be in the 2.2 series. This should ease a lot of confusion in this area. As always, if you run into any problems, please report them on the tracker since a 1.3.2 release is not far away.

In other news, it appears that you should be very careful when you complain about how software isn't being maintained. I had been keeping my own fork of Gitjour, which is a tool for sharing repositories over local networks when either your Internet connection is unreliable (like at tech conferences) or when you can't be bothered to host a repo somewhere. My fork allowed gitjour to work with Avahi and had a few other tweaks and had never made it back upstream, but it seemed like there was a lot of uncoordinated development on them across github forks as well.

Somehow my call for the maintainers to step up got turned around into me becoming the maintainer. Not exactly what I had expected, but I was happy to be able to help out. I ended up pushing out my fixes in a release as well as pulling in some nice web-related stuff from Alex. gitjour web will now throw up an instaweb instance, and gitjour browse will let you look through all the instawebs being advertised locally. So if you're headed to a conference at which you plan to hack any time soon, be sure to not leave home without a copy of gitjour. You know the sudo gem install drill.

Finally, there's been a recent turn of events that's left me without work for the present. As I've hopefully made obvious, I've got a pretty decent portfolio of free software contributions, but if you're not convinced, visiting http://technomancy.us/projects should do the trick. My résumé may also be of interest. Thanks for reading.

« older | 2009-03-22T06:12:49Z | newer »