[Rubygems-developers] Version number format

Chad Fowler chad at chadfowler.com
Mon Mar 29 22:19:31 EST 2004

On Mon, 29 Mar 2004, Jamis Buck wrote:

# Richard Kilmer wrote:
# > Because we do numeric comparison of versions, having text in it would be 
# > rather hard to manage.  Why not just increment the 0.3.0 to 0.3.1 ?
# > 
# > -rich
# > 
# That'll be my fallback option, since it works. :)  However, my thought 
# was this: there are projects out there (quite a few of them) that 
# provide the current "bleeding-edge" versions of their software, fresh 
# out of CVS, bundled up and ready to run.  Most people, of course, would 
# not want to use these, since they are often buggy and may not even run, 
# but if someone wants to see whether a bug they've encountered in the 
# stable version has been taken care of in CVS or not, this is a nice option.
# Thus, it would be nice to have a "snapshot" version--I could have a 
# script run everytime I check something into CVS, which would essentially 
# create a gem file for the current state of the sources. I could put this 
# up on my site, and the version number would never change, but some other 
# indicator would show that it is a snapshot.
# Incrementing the version number doesn't really show that--I mean, 0.3.1 
# is still a valid release. This is really a way to have a "non-release" 
# of your software.
# If nothing else, I may arbitrarily say that x.x.0 releases are CVS 
# snapshots, and non .0 releases are "real" releases.  It still feels 
# kludgy, though.
# If I am the only one that sees value in this, then I'll stop yammering. 
# I may tinker with the rubygems sources to see if I can come up with an 
# elegant way of doing this anyway, though. ;)

I'm traveling again and having email troubles.  Here's what I tried to 
send earlier. :)

David and I were just talking about this on AIM.  I think we both 
understand a scenario in which this would be useful.  David's proposed 
solution (which I think is the most simple and elegant) is to use a 
different gem name for the snapshots.  You could do, for example, 
captcha-snapshot and have a bleeding edge versioning scheme that you 
update.  This way, the following would always get you the latest snapshot:

gem --remote --install captcha-snapshot

The downside is you have to require_gem("captcha-snapshot"), but given the 
way gems works, you would most likely only be doing this in one place, so 
it wouldn't be a big deal to change when you get to general release for 
libs that require the snapshot.

What do you think?


More information about the Rubygems-developers mailing list