On 1/15/07, Kirk Haines <[EMAIL PROTECTED]> wrote: > On 1/15/07, Chad Woolley <[EMAIL PROTECTED]> wrote: > > > You are probably right. However, the RubyGems "Rational Versioning > > Policy" ( http://rubygems.org/read/chapter/7 ) doesn't seem to account > > for the beta/release candidate phase of the development cycle for a > > post-1.0 release. It looks like the best you can do is to assume that > > any x.0.0 release is a release candidate, and should be treated as > > such. However, there's still no standard way for a gem developer to > > indicate that a given post-x.0.0 version is now REALLY finished, and > > should be safe for widespread use. > > Nope, and I doubt that there ever will be. Everybody does versioning > differently, so all a person can ever really do is look at the project > information and then judge the version number in the context of the > other project information.
Here's the answer I got on the RubyGems developer list: http://rubyforge.org/pipermail/rubygems-developers/2007-January/002443.html "The typical workaround is to not post release-candidate gems to Rubyforge, and instead host them on a separate gem server." A reasonable answer, especially since it's so easy to set up a local gem server, and point to that on your RubyForge project page (or even host the gem files directly on your RubyForge account). -- Chad _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
