* Remove the accidental require * Don't expect no exceptions
The tests found a bug in the previous fix - for the "update to latest" part, one should use ">", not ">=", so that in this case the latest version is not found, stopping unnecessary install. Also, reusing a local variable makes my brain hurt, so try to come up with new names when the object behind "version" changes.
This test tries to update to latest version n from version n-1 with update --system n, which fails as the latest version is erronously detected.
I've found mention online that the order of the files from Dir.glob is not guarenteed. Since the tests fail for me with a reversed order, force the order to be alphabetical.
This was not possible before because #which_to_update was used, which doesn't work when specifying the highest current version on the servers, as it specifies "> requested version". IMHO, #which_to_update is not really what is semantically required for the rubygems-update updating. So instead, copy the smallish parts actually used and hardcode the rest inside #update_rubygems. Also, distinguish in the error message between really being on the highest version, and the requested version not having been found.
- Fixed lightweight specifications so `gem rdoc` will generate proper documentation
…won't be installed is unsatisfied.
And strip the base directory which is a valid Windows path.
…0.1, 2.2.0, 2.5.11 or rdoc trunk (3.6)
Doing File.utime on a directory with open handles raises Errno::EACCES on Windows. Using another directory inside @tempdir works around that issue Hint: smells like open file remains open? Gotta love Ruby's GC...
Fix deprecation date for Gem.cache