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.4", "< 1.5"] should not be satisfied by 1.5.0.beta.0
[">= 1.4.beta", "< 1.5"] should not be satisfied by 1.5.alpha.0
[">= 1.4.0", "< 1.5.0"] should not be satisfied by 1.5.0.beta.0
[">= 1.4.0.beta", "< 1.5"] should not be satisfied by 1.5.0.alpha.0
[">= 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?
Add TestGemRequirement cases for spermy pre-release matching
Fix typo in 1ee3b2a test
Make assert,refute satisfied messages more clear
Add more TestGemRequirement cases for ranges and pre-release, cleanup
Split TestGemRequirment.test_satisfied_by_spermy_inplace_pre into two…
This pull request fails (merged 069b6e6 into 1e97cce).
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