[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

gem pessimistic versioning - bug?

Ara.T.Howard

8/22/2006 3:13:00 PM

3 Answers

Jim Weirich

8/22/2006 6:20:00 PM

0

unknown wrote:
> can anyone provide a good reason why both of these should not work?
>
> harp:~ > ruby -r rubygems -e' require_gem "dynaload", "~> 0.1"; p
> Dynaload::VERSION '
> "0.2.0"

~> 0.1 implies that versions 0.x are appropriate choices. 0.2.0 matches
this criteria.

$ irb --simple-prompt
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("0.0"))
=> false
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("0.1"))
=> true
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("0.2"))
=> true
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("0.2.0"))
=> true
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("0.2.0.0.0.0"))
=> true
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("0.3"))
=> true
>> Gem::Requirement.new("~> 0.1").satisfied_by?(Gem::Version.new("1.0"))
=> false

> harp:~ > ruby -r rubygems -e' require_gem "dynaload", "~> 0.1.0"; p
> Dynaload::VERSION '
> /home/ahoward//lib/ruby/site_ruby/1.8/rubygems.rb:204:in
> `report_activate_error': RubyGem version error: dynaload(0.2.0 not ~>
> 0.1.0) (Gem::LoadError)
> from /home/ahoward//lib/ruby/site_ruby/1.8/rubygems.rb:141:in
> `activate'
> from /home/ahoward//lib/ruby/site_ruby/1.8/rubygems.rb:37:in
> `require_gem_with_options'
> from /home/ahoward//lib/ruby/site_ruby/1.8/rubygems.rb:31:in
> `require_gem'
> from -e:1

~> 0.1.0 implies that versions 0.1.x are appropriate choices. Version
0.2.0 does not meet that criteria.

$ irb --simple-prompt
>> Gem::Requirement.new("~> 0.1.0").satisfied_by?(Gem::Version.new("0.1.0"))
=> true
>> Gem::Requirement.new("~> 0.1.0").satisfied_by?(Gem::Version.new("0.1"))
=> true
>> Gem::Requirement.new("~> 0.1.0").satisfied_by?(Gem::Version.new("0.1.1"))
=> true
>> Gem::Requirement.new("~> 0.1.0").satisfied_by?(Gem::Version.new("0.2"))
=> false
>> Gem::Requirement.new("~> 0.1.0").satisfied_by?(Gem::Version.new("0.2.0"))
=> false

> in addition, the error is most misleading...

Suggestions are welcome ...

> i'm unclear why it wouldn't simply do
>
> version = version.split(%r/\./).first(2).join('.')
>
> to ignore the trailing digit.

(1) The number of 'digits' compared depends on the number of 'digits' in
the requirement. It is not fixed at 2. ('digits' are in quotes because
version numbers can be more than single digits, but you know what I
mean).

(2) The trailing 'digit' can't be ignored. It must be equal or greater
than the last 'digit' of the requirment.

> i guess i'm thinking that this is a bug.

Looks OK to me.

-- Jim Weirich

--
Posted via http://www.ruby-....

Ara.T.Howard

8/22/2006 7:23:00 PM

0

Jim Weirich

8/22/2006 8:30:00 PM

0

Heh, I saw Ara's email to me before I saw the responce here. Here's my
reply:

ara.t.howard wrote:
> but why should
>
> 0.1.0 __not__ imply that 0.2.x is appropriate?
>
> according to the 'sane versioning policy' there is no reason i can think of
> that it would not be?

Policy is policy. The pessimistic requirement operator is mechanism. In
this case, the mechanism supports the policy but does not dictate the
policy.

Although the recommend policy uses the major version number to denote
changes in compatibility, the "~>" operator does not assume the same. It
this allows it to work with other similar policies that might use a
different version level.

[...]
>> (2) The trailing 'digit' can't be ignored. It must be equal or greater
>> than the last 'digit' of the requirment.
>
> but that doesn't make logical sense and ignores the semantics of gem versions
> though? according to the semantics any version
>
> 0.2.x
>
> is backward compatible with 0.1.x and 0.0.x

Yes, but although version 0.2.3 of a library might be compatible with
client software written to version 0.2.0, the reverse is not true.
Client software written to version 0.2.3 will (possibly) not work with
earlier versions of the library. Since it is the client software
specifying the requirement, that last digit becomes important.

The ~> is really two statements at once:

"~> 1.2" Says:

(1) There is a minimum level of functionality required, and that minimum
level is version 1.2.x. Version 1.1.x will not cut it.

(2) There is an assumption that any version in the 1.x series will be
backwards compatible, so that version 1.99999999 is OK, but that version
2.0 is not expected to be backwards compatible and will not be accepted.

-- Jim Weirich


--
Posted via http://www.ruby-....