On Wed, 23 Aug 2006, Jim W. wrote:
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.
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?
Gem::Requirement.new("~> 0.1.0").satisfied_by?(Gem::Version.new(“0.2.0”))
=> false
this does not agree with the gem versioning policy though?
in addition, the error is most misleading…
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