On Jan 15, 2007, at 09:10, Chad Woolley wrote:
> There's an interesting thread on the Mongrel Users list, where a
> Debian package manager is asking questions about RubyGem's versioning
> standards.
>
> Here's my last post which I think summarizes most of it:
>
> http://rubyforge.org/pipermail/mongrel-users/2007-January/002694.html
>
> Basically, the question is - how do you specify a release candidate
> version for a version that is post 1.0?
Typically I've seen release candidates go into a project-specific gem
repository. Jim has one, Rails has one, and I think there's a few
others I don't know about (maybe why's projects?).
That's not really the answer you were looking for, though.
> Specifically, if people are automatically pulling all the latest
> version of a gem (">= 1.0.0"), how can they say "I ONLY want stable
> releases, not alpha versions or
> release candidates"? Does RubyGems support any version numbering
> (or version specifications) other than the "[(in)equality operator]
> x[.y.z]" pattern, where x, y, and z are numeric?
You can specify a range, with version requirements, for example >=
1.0 < 1.1. (I'm not sure what the exact syntax is, though.)
> If not, is this an unnecessary limitation? What are workarounds?
Perhaps. I don't think it frequently comes up. The typical
workaround is to not post release-candidate gems to Rubyforge, and
instead host them on a separate gem server.
--
Eric Hodel - [EMAIL PROTECTED] - http://blog.segment7.net
YOU LIT MY GEM ON FIRE!
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
