Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Aug 18, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.3)

Can you help keep this open source service alive? 💖 Please sponsor : )

nobu and others added 28 commits August 18, 2025 10:08
The current oldest support Ruby version is 3.2. And Ruby 3.2 bundled
Bundler 2.5. It means RG 4.0 can drop to support Bundler 2.2.

ruby/rubygems@592ac09b5c
…ation warning

Like others, it's a remembered option which we are deprecating in favor
of configuration.

ruby/rubygems@9ea55e0df2
The `bundle list` command is a convenient way for human to know what gems and versions are available. By introducing a `--format=json` option, we can provide the same information to machines in a stable format that is robust to UI additions or modifications. It indirectly supports  `Gemfile.lock` modifications by discouraging external tools from attempting to parse that format.

This addition allows for the scripting of installation tools, such as buildpacks, that wish to branch logic based on gem versions. For example:

```ruby
require "json"

command = "bundle list --format=json"
output = `#{command}`
raise "Command `#{command}` errored: #{output}" unless $?.success?

railties = JSON.parse(output).find {|gem| gem["name"] == railties }
if railties && Gem::Version.new(railties["version"]) >= Gem::Version.new("7")
  puts "Using Rails greater than 7!"
end
```

The top level is an object with a single key, "gems", this structure allows us to add other information in the future (should we desire) without having to change the json schema.

ruby/rubygems@9e081b0689
…st in a specific case

If upgrading `foo` needs an indirect dependency to be downgraded,
Bundler would not be able to upgrade foo.

This is because when calculating the latest resolvable version of foo,
Bundler was still adding lower bound requirements on the locked versions
of all dependencies to avoid downgrades, effectively pinning foo to a
version older than the latest.

To fix this, instead of creating a second "unlocked" definition to
figure out the latest resolvable version, create a second unlocked
resolver, and DO NOT add lower bound requirements to it.

ruby/rubygems@00cc0ecc69
We had actually cancelled this change. After a second look though, it
does seem like a reasonable plan since `bundle list` makes more sense
for listing gems, and `bundle info` makes more sense for showing info
about a particular gem. `bundle show` is a strange mix of both.

Let's schedule this for Bundler 5.

ruby/rubygems@7071a1e82e
For synopsis, subcommand and flag documentation like other commands do.

ruby/rubygems@f528029756
Name default value placeholders in a more standard way. That's what our
specs check, but they don't yet work for subcommand flags.

ruby/rubygems@c589899cb8
Make synopsis, subcommands, and CLI flags use a format consistent with
the other docs, and also reword some sentences for clarify.

ruby/rubygems@9272169ad0
To save some unnecessary `bundle install` commands.

ruby/rubygems@61e7d9d09a
We had them duplicated, but with slightly different features:

* The ones in `other/cli_man_pages.rb` enforced a specific structure to
  document CLI options, so were less likely to have false positives.

* The ones in `quality_spec.rb` were able to check subcommands and their
  flags.

This commit merges both and preserves the best of both.
@pull pull bot locked and limited conversation to collaborators Aug 18, 2025
@pull pull bot added the ⤵️ pull label Aug 18, 2025
@pull pull bot merged commit 7ddc53b into turkdevops:master Aug 18, 2025
1 of 2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants