[Rubygems-developers] Gem#status?

Berger, Daniel Daniel.Berger at qwest.com
Tue Nov 11 10:59:04 EST 2008


>From the journal of Phil Hagelberg:


"It'd be better if Rubygems allowed 2.2.0.a to be treated specially as a
prerelease version that would be superceded by a later real release, and
that's what Josh Susser, Alex Vollmer, and myself worked on."

I'd rather not get into mangling version numbers in an attempt to parse
every arcane schema that users come up with in the wild. However, I'm
not opposed in principle to the notion of a gem "status" that would more
or less be in line with the "status" field for RAA downloads, where a
gem at 'stable' status (or 'production', or whatever you want to call
it) would supercede a gem at 'prerelease' status.

So, let's say on November 1, 2008 I want to put out a prerelease version
of "foo" 1.0.0. It would look like this:

Gem::Specification.new do |gem|
   gem.name    = 'foo"
   gem.version = '1.0.0"
   gem.status  = Gem::Status::PRERELEASE # Or ALPHA, or whatever

A month later I put out the "official" release:

Gem::Specification.new do |gem|
   gem.name    = 'foo"
   gem.version = '1.0.0"
   gem.status  = Gem::Status::STABLE # The default, btw

Now I have two gems out there at 1.0.0, but one is tagged as a
prerelease gem and one is tagged as stable gem. If a user does "gem
install foo", they'll get the 'stable' gem, since it's understood to be
the "real" version. If a user wants a specific release version they
could use a command line switch, e.g. "gem install foo

Then we just have to work out all the status options and determine their

Seem reasonable?



This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

More information about the Rubygems-developers mailing list