ruby.git/spec/bundler/lock, branch v4.0.3

[ruby/rubygems] Fix triple spacing when generating lockfile

2025-11-14T00:19:56+00:00

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

[ruby/rubygems] Now ruby/rubygems is the canonical repository url

2025-10-20T06:52:54+00:00

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

[rubygems/rubygems] Fix `bundle install` when the Gemfile contains "install_if" git gems:

2025-10-09T11:37:27+00:00

- Fix https://github.com/rubygems/rubygems/pull/8985
- ### Problem

  If you have a Gemfile that contains a `install_if` git gem, it will
  be impossible to add other gems in the Gemfile and run
  `bundle install`, you'll get a "The git source [...] is not yet
  checked out".

  ### Context

  The change that modified this behaviour was in https://github.com/rubygems/rubygems/commit/abbea0cc94dd,
  and the issue is about the call to `current_dependencies`.
  This call filters out irrelevant dependencies such as the one that
  get condtionnally installed. By doing so, we skip over setting
  the source based of the lockfile for that dependency
  https://github.com/rubygems/rubygems/blob/ade324bdc8ea77b342f203cb7f3929a456d725ed/bundler/lib/bundler/definition.rb#L978

  Ultimately, because of this, the dependency source doesn't have
  any additional information such as the `revision`. Down the line,
  when we end up to converge the spec, Bundler will attempt to get the
  revision for that spec but won't be able to because the git source
  isn't configured to allow running git operations.

  ### Solution

  Filter out the irrelevant only spec only after we have set its
  source.

https://github.com/rubygems/rubygems/commit/d2af439671

[rubygems/rubygems] Switch `cache_all` to be `true` by default

2025-09-19T10:30:10+00:00

And make it a standard setting.

https://github.com/rubygems/rubygems/commit/17e356fa94

[rubygems/rubygems] Fix outdated lockfile during `bundle lock` when source changes

2025-09-12T05:03:29+00:00

When the source used to be git and switches back to rubygems,
it is possible that the git source contains a version that
ruybgems doesn't know about yet.

So don't add the locked spec to the base resolve, and also don't add a
lower bound requirement on the version, since the version in the new
source may actually be lower.

https://github.com/rubygems/rubygems/commit/85514e3a1e

[rubygems/rubygems] Enforce checksums strictly for registry gems

2025-08-18T03:31:51+00:00

https://github.com/rubygems/rubygems/commit/05199ae0c1

[rubygems/rubygems] Fix incorrect error message capitalization

2025-08-18T03:31:51+00:00

https://github.com/rubygems/rubygems/commit/d41b8d303c

[rubygems/rubygems] Simulate Bundler 4 in a better way

2025-06-25T23:06:48+00:00

Overriding the version constant feels too magic and creates a set of
problems. For example, Bundler will lock the simulated version, and that
can cause issues when the lockfile is used under an environment not
simulating Bundler 4 (it will try to auto-install and auto-switch to a
version that does not exist).

On top of that, it can only be configured with an ENV variable which is
not too flexible.

This commit takes a different approach of using a setting, which is
configurable through ENV or `bundle config`, and pass the simulated
version to `Bundler::FeatureFlag`. The real version is still the one set
by `VERSION`, but anything that `Bundler::FeatureFlag` controls will use
the logic of the "simulated version".

In particular, all feature flags and deprecation messages will respect
the simulated version, and this is exactly the set of functionality that
we want users to be able to easily try before releasing it.

https://github.com/rubygems/rubygems/commit/8129402193

[rubygems/rubygems] Remove no longer necessary workarounds for restarts

2025-06-24T03:10:50+00:00

Since we no longer pass ruby CLI flags in our spec commands, we no
longer need the previous workaround and can get the realworld code
tested.

https://github.com/rubygems/rubygems/commit/fd92c855fb

Skip to Bundler 4 directly

2025-06-19T01:23:36+00:00