Failing test cases for requirements range expressions and prereleases #350

wants to merge 6 commits into


None yet

5 participants

dekellum commented Jul 4, 2012

Here is an oddity, continued from #349:

Prereleases are included in >=, < requirement ranges, even when they don't have prerelease segments. But anyone specifying for example < 1.5.0 is most certainly not expecting to use 1.5.0.beta.0 if they happen to have it installed.

Failed test output:

 1) Failure:
test_satisfied_by_range_postfix(TestGemRequirement) [./test/rubygems/test_gem_requirement.rb:387]:
[">= 1.4", "< 1.5"] should not be satisfied by 1.5.0.beta.0

  2) Failure:
test_satisfied_by_range_pre_inplace(TestGemRequirement) [./test/rubygems/test_gem_requirement.rb:351]:
[">= 1.4.beta", "< 1.5"] should not be satisfied by 1.5.alpha.0

  3) Failure:
test_satisfied_by_range_3_postfix(TestGemRequirement) [./test/rubygems/test_gem_requirement.rb:402]:
[">= 1.4.0", "< 1.5.0"] should not be satisfied by 1.5.0.beta.0

  4) Failure:
test_satisfied_by_range_with_pre_postfix(TestGemRequirement) [./test/rubygems/test_gem_requirement.rb:420]:
[">= 1.4.0.beta", "< 1.5"] should not be satisfied by 1.5.0.alpha.0

  5) Failure:
test_satisfied_by_range_inplace(TestGemRequirement) [./test/rubygems/test_gem_requirement.rb:371]:
[">= 1.4", "< 1.5"] should not be satisfied by 1.5.alpha.0

Also, a command line example:

% gem list bundler
*** LOCAL GEMS ***
bundler (1.2.0.pre.1, 1.1.3, 1.1.0, 1.1.rc.8)

% ruby -rubygems -e "gem( 'bundler', [ '>= 1.1', '< 1.2' ] ); require 'bundler'; puts Bundler::VERSION"

Is this all expected behavior?


This pull request fails (merged 069b6e6 into 1e97cce).

@drbrain drbrain was assigned Nov 28, 2012
drbrain commented Dec 10, 2012

Prereleases were always intended to be a "buyer beware" or "I know what I'm doing" feature. Users of prereleases are expected to pay attention to potential bugs in the releases they install. Due to the potential for bugs they'll need to be sure they're using the latest prerelease and upgrade to the latest version after the official release.

I don't think it's worth our time to attempt to implement a fix for these failing test cases.

We will review a patch that addresses the failures you have created here.

I'm moving this issue from the 2.0 milestone.


Checking in to see if there is interest here or should we just close this one.


IMHO its fine to close this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment