gem pessimistic versioning - bug?

[ara.t.howard]

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"


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


in addition, the error is most misleading... i'm unclear why it wouldn't simply do

version = version.split(%r/\./).first(2).join('.')

to ignore the trailing digit.

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

-a

 

[Jim Weirich]

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=> 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=> 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

 

[ara.t.howard]

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

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?

i think i may not have been clear. it think it's correct that

ruby -r rubygems -e' require_gem "dynaload", "~> 0.1"; p Dynaload::VERSION '

load 0.2.0

i thinks an error that

ruby -r rubygems -e' require_gem "dynaload", "~> 0.1.0"; p Dynaload::VERSION '

does __not__


what i mean is, in what way is '0.2.0' not pessimistically compatible with
'0.1.0'?

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

why is that though? i mean, if one follows the gem version rules 0.2.0 __is__
backward compatible with 0.1.0? it simply has some added features. am i
missing something?

=> false

this does not agree with the gem versioning policy though?

Suggestions are welcome ...

"#{ requested_version } is too specific or not backward compatible with #{ found }"

(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.

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


thanks for the reply btw.

cheers.

-a

 

[Jim Weirich]

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

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.

[...]

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