When using something like `bundle config set foo false`, the config value is converted via `Bundler::Settings#converted_value`, so the stored value becomes `false` instead of the string `"false"`. Because of that, passing `Bundler.settings[name]` directly to an `if` statement can execute `exit 1` even when the value is actually configured.

Since config values do not appear to become `nil` explicitly, use `nil?` to determine whether the value is configured.

https://github.com/ruby/rubygems/commit/8fd32cb611

Refactor the code based on the feedback in https://github.com/ruby/rubygems/pull/9505#discussion_r3167085736 .

https://github.com/ruby/rubygems/commit/153abcb5e3

Fix https://github.com/ruby/rubygems/pull/3215

Change the exit status to 1 when trying to `get` a config key that does not exist, as shown below.

```sh
$ bundle config get foo

Settings for `foo` in order of priority. The top value will be used

You have not configured a value for `foo`

$ echo $?
1
```

It seems that showing “Settings for `foo` in order of priority. The top value will be used” when the key does not exist is not very meaningful, but for now I have left the behavior unchanged except for the exit status.

In the tests, some existing cases try to `get` a missing config without `raise_on_error: false`, so set the value in advance or add `raise_on_error: false` to handle them.

https://github.com/ruby/rubygems/commit/73205e3d64

Add the recent developer meeting, we discussed switching from using
pessimistic versioning by default to using optimistic versioning by
default. This is the a step in that direction. It makes bundle add
without a explicit version given to use >= (optimistic) instead of
~> (pessimistic).

With this, the bundle add --optimistic option is now ignored, since
the behavior is now the default. This add a --pessimistic option to
set a pessimistic version.

https://github.com/ruby/rubygems/commit/eed378086b

Update the gem creation guide links in the CLI output and gemspac template.
The previous Bundler guide URL now redirects to RubyGems Guides.

https://github.com/ruby/rubygems/commit/0b469edf03

- ### Problem

  I'd like to normalize the number of workers when downloading gems
  and use the `BUNDLE_JOBS` configuration (or default to
  `Etc.nprocessors`).
  Right now the number of workers when doing parallel work seems a bit
  random.

  ### Benchmarks

  **Downloading 40 git gems**

  === Comparison Summary ===

  Scenario: git-gems (40 gems)
                             Cold     +/-                        Warm     +/-
  ------------------------------------------------------------------------------
  more-downloads            7.94s   1.44s  baseline             5.02s   0.31s  baseline
  master                   14.59s   1.67s  83.7% slower         5.72s   0.30s  13.9% slower

  _________________________________

  **Downloading 249 gems from a fake gemserver with a 300ms latency**

  === Comparison Summary ===

  Scenario: no-deps (249 gems)
                             Cold     +/-                        Warm     +/-
  ------------------------------------------------------------------------------
  more-downloads           11.11s   0.66s  baseline             1.23s   0.14s  baseline
  master                   16.89s   0.60s  52.0% slower         1.03s   0.09s  16.2% faster

  ### Context

  I originally added those workers count in

  1. https://github.com/ruby/rubygems/pull/9087/changes#diff-524173391e40a96577540013a1ad749433454155f79aa05c5d0832235b0bdad1R11
  2. https://github.com/ruby/rubygems/pull/9100/changes#diff-04ae823e98259f697c78d2d0b4eab0ced6a83a84a986578703eb2837d6db1a32R1105

  For 1. (downloading gems from Rubygems.org)I opted to go with a
  hardcoded worker count of 5 and not anything higher as I was
  that we could hammer RubyGems.org. I think this concern
  is not valid, because requests to download gems don't even hit
  RubyGems.org server as there is the fastly CDN in front of the s3
  bucket.

  For 2. I went with a worker count of 5 to match, without giving this
  a second thought.

https://github.com/ruby/rubygems/commit/170c9d75c2

https://github.com/ruby/rubygems/commit/300cc0c223

https://github.com/ruby/rubygems/commit/5d3fbf0280

https://github.com/ruby/rubygems/commit/9420974db7

https://github.com/ruby/rubygems/commit/26dab848c5