On 1/15/07, Filipe <[EMAIL PROTECTED]> wrote: > On Sat, 13 Jan 2007, Chad Woolley wrote: > > >> Hum... then -rc1? :D Well, I take a look at this when generating the rake > >> task. > > > > I *THINK* this is not the rubygems standard. See this: > > > > http://rubygems.org/read/chapter/16
... > > 1. Why does debian or apt need to distinguish between release > > candidates? Is this automatically tied to -dev packages or something? > > No, it's just because we've a file called watch, with this content: > > http://mongrel.rubyforge.org/releases/gems/mongrel-([0-9\.]*)\.gem > > And a tool that checks the site and remind me that there is a new > version. > > Ow, and the package version in debian always has the same version than > upstream. So I thought it is someway stranger to have a release > candidate package called "1.0". I do agree this is rather strange, but it's not unheard of. In any case, I don't think it's appropriate for a packaging system to try to enforce constraints on the versioning standards of the the software it packages. See this for all the various flavors of versioning standards: http://en.wikipedia.org/wiki/Version#Software_versioning_schemes Some of these allow identification of pre-release or beta versions while still conforming to the RubyGems standard. For example, the Linux versioning approach (odd numbers for development releases, even for stable) would be compatible: http://en.wikipedia.org/wiki/Version#Odd-numbered_versions_for_development_releases HOWEVER, the linux approach WOULD cause problems when you consider that RubyGems own version specification approach is primitive - you can only say things like "> x.y" or "<= x.y" I'll point this thread out to the RubyGems list, I'm curious what they would have to say. At a minimum, I think the RubyGems versioning standard docs could use some clarification. -- Chad _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
