Fix prereleases not being considered by gem version promoter when there's no lockfile

[siegfault]

What was the end-user or developer problem that led to this PR?

Pulled out some spec changes as a result of #5258 (review) (

However, the specs added in the last commit raise some questions, since the current behavior feels quite surprising and I suspect we may want to tweak the implementation instead of codifying the current behavior in specs. I also have some minor comments about wording.

) and a bug fix mentioned in #5258 (comment).

What is your fix for the problem, implemented in this PR?

Spec changes

Add tests for pre, move more of the setup into a helper method, and restructure tests.

There seem to be five considerations for these tests (level, pre, strict, locked, and whether the current version is a prerelease version, though the last one overlaps with pre and didn't seem to behave how I expected under test). Rather than write out the 16 (/32 if the last consideration is real) combinations, I wrote most with independent tests for each value. The existing combined tests were maintained (level vs strict) because these seem the most interrelated.

Bug Fix

Prereleases are NOT considered even when the dependency specification includes a prerelease segment, if the dependency is not locked. To me that doesn't make sense, because I could create a Gemfile with say gem "rails", ">= 7.0.0.beta1" and I'd expect prereleases considered there even if there's no lock file yet.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[siegfault]

@deivid-rodriguez the tests are more or less the same commit from that original PR. I made sure all the cases are still covered, and fixed some new kwargs that have been added since. Re: your comment, I wonder whether the current behavior feeling surprising is due to how I worded some of the tests w.r.t. 'favors'. Ultimately, what the GemVersionPromoter returns is flipped (I believe here:

rubygems/bundler/lib/bundler/resolver.rb

Line 313 in 849342b

@gem_version_promoter.sort_versions(package, versions).reverse

), so what's favored here is ultimately the opposite of what's selected/used. Very open to better wording to make this less confusing! As well as any other suggestions you had. Thank you!

[deivid-rodriguez]

Looks awesome, thanks for following up on this!

[deivid-rodriguez]

I think this is what was surprising to me. The other levels remove downgrades, but this one (the default), does not. I think this complicates things for Bundler outside of the gem version promoter because it needs to explicit add lower bound requirements to dependencies and I think it may be to workaround this.

Nothing to fix in this PR, but I think we may be able to remove a bit of complexity but making level=major behave like the other levels.

[siegfault]

Ah, gotcha. Yeah that had tripped me up a couple times. I'm not currently at the computer, but I wonder if changing

rubygems/bundler/lib/bundler/gem_version_promoter.rb

Line 80 in 3586d71

return specs if locked_version.nil? || major?

with

-       return specs if locked_version.nil? || major?
+       return specs if locked_version.nil?

would fix that. Happy to try it either on this branch or a follow up!