| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/ruby/rubygems/commit/234e2b7d5f
|
|
The git source exclusion in `find_source_requirements` introduced by
ruby/rubygems#9234 relies on `locked_requirements` to backfill the gap
for sources used only by --without groups. Without a Gemfile.lock —
e.g. an initial `BUNDLE_ONLY=ci bundle install` where a default-group
gem from a git source is shifted into the "excluded" set — that
fallback is absent, and the source's indirect dependencies fall
through to the default rubygems source, causing resolution to fail.
Gate the exclusion on `nothing_changed?` so it only applies when the
lockfile is guaranteed to cover the excluded sources.
Fix ruby/rubygems#9536
https://github.com/ruby/rubygems/commit/89ed2bc9ef
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
The hook receives a Bundler spec proxy (Bundler::EndpointSpecification
or Bundler::RemoteSpecification) that responds to the Gem::Specification
API but is not itself a Gem::Specification instance. Plugins doing
strict is_a? checks would break on the previous wording.
Also clarify the cache-hit language: the hook does not fire when the
initial download-cache check in fetch_gem finds the .gem already on
disk, but Bundler.rubygems.download_gem also has a race-protection
early return on the same path, which the previous wording obscured.
https://github.com/ruby/rubygems/commit/93fe617ea8
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
Wrap the fetch/checkout operations in begin/ensure so the after
hook fires even when the underlying fetch raises. This matches
the existing GEM_AFTER_INSTALL hook, which fires on both success
and failure paths (via internal error-to-state conversion in
ParallelInstaller#do_install).
Without this, plugins relying on before/after pairs for cleanup
or timing would see unbalanced hook invocations whenever a
network or checkout error occurs.
https://github.com/ruby/rubygems/commit/d33e3eb4a4
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
Arrange events.rb by actual firing order so the file reads as a
timeline of bundler's lifecycle: Gemfile eval, install-all bracket
(with per-gem fetch, git fetch, and install nested inside), then
require-all bracket (with per-gem require nested inside).
Also clarify the git fetch hook docstrings: the hook fires around
both remote fetch and checkout, not only fetch.
https://github.com/ruby/rubygems/commit/acc0659ffc
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
Adds four new hook points:
- before-fetch / after-fetch: fires in Source::Rubygems#download_gem
around actual network downloads, avoiding noise from cache hits.
- before-git-fetch / after-git-fetch: fires in Source::Git#specs
around fetch/checkout operations.
Based on the original proposal in #8162 with adjustments:
- Moved gem fetch hooks from fetch_gem_if_possible to download_gem
so they only fire on actual network I/O.
- Dropped the source argument since spec.source provides it.
- Renamed git hooks to before-git-fetch / after-git-fetch for
consistency with the existing before-*/after-* pattern.
- Removed GEM_BEFORE_FETCH/GEM_AFTER_FETCH from Source::Git#install
since using gem fetch events for git sources is semantically
inconsistent.
https://github.com/ruby/rubygems/commit/34c4a46ef2
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
https://github.com/ruby/rubygems/commit/fefe97c0bd
|
|
This changes the gemspec and Gemfile to use optimistic versions for
dependencies.
https://github.com/ruby/rubygems/commit/92b0305c8b
|
|
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
|
|
not set
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
|
|
complete_platform validates platform-specific candidates returned by
spec.source.specs.search, which are remote specs that do not carry
the override list. Borrow the override list from the LazySpec exemplar
already in scope so platform-variant validation uses the same effective
metadata as the install/resolve path.
Also propagate the overrides onto the synthesized LazySpec built from
platform_spec. Without this, the next complete_platform call could
pick the synthesized variant as its exemplar (it is now in the set
returned by lookup) and fall back to strict matching, dropping
platforms that the user's override would otherwise allow.
https://github.com/ruby/rubygems/commit/205955c5b3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
SpecSet previously kept its own @overrides and a with_overrides setter
that had to be chained on every SpecSet.new(...) site (~13 sites in
Definition alone). Two Codex review rounds both flagged forgotten
chains in different SpecSet construction paths, which is exactly the
class of bug the chain pattern invites: it is purely "remember to
write" with no compiler help.
Move the override list to LazySpecification#overrides instead. The
LazySpec is the natural carrier — it is the value object the resolver
and install paths already pass around, and choose_compatible already
read overrides off it. Override.attach(specs, overrides) is added as
the dual of Override.find_for so Definition (after lockfile load) and
Resolver (after solve_versions) can populate the overrides on every
LazySpec they hand out, and LazySpecification.from_spec carries the
list forward when one LazySpec spawns another. Generic spec types
(StubSpecification, plain Gem::Specification, RemoteSpecification)
are intentionally ignored so generic metadata callers (SelfManager,
materialize-time strict checks) keep their current strict semantics.
SpecSet drops attr_accessor :overrides, the @overrides initialisation,
the with_overrides cascade, and reverts SpecSet#valid? to the strict
matches_current_metadata? check. Every SpecSet.new(...) site in
Definition stops chaining .with_overrides — the LazySpecs already
carry the context.
https://github.com/ruby/rubygems/commit/fc1e8d4d7e
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
overrides
SpecSet#with_overrides cascaded into each contained spec via
`respond_to?(:overrides=)`. RemoteSpecification#respond_to? forwards
to _remote_specification, which materializes the backing gemspec just
to answer the predicate. spec/runtime/require_spec.rb verifies that
Bundler does not load gemspecs it does not need by deliberately
poisoning one with `raise 'broken gemspec'`; the cascade tripped that
guard and made `Bundler.setup` blow up.
Gate the cascade on `is_a?(LazySpecification)` instead. Only
LazySpecification declares `attr_accessor :overrides` (used by
`#choose_compatible`), so the predicate is equivalent for any spec we
ever set overrides on, and it never triggers the lazy gemspec load.
https://github.com/ruby/rubygems/commit/2a1e7d5c23
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
SpecSet#incomplete_specs_for_platform constructed a fresh
self.class.new(@specs) for platform validation but never copied
@overrides. Platform-validity decisions therefore evaluated strict
required_ruby_version / required_rubygems_version metadata even when
resolution was running with overrides, so a metadata override could
allow a gem everywhere except platform validation, where the platform
might be marked incomplete and pruned.
Carry @overrides forward via with_overrides on the cloned SpecSet.
https://github.com/ruby/rubygems/commit/11b7c58a5a
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Definition#resolve falls back to an existing lockfile when nothing
about the Gemfile or the locked deps changed. The two SpecSet rebuild
paths (deleted_deps subset and the redundant-platform-specific-gems
fallback) constructed fresh SpecSet instances without carrying
@overrides forward, so any LazySpec produced from them lost its
override context. After Step G that mattered: an :all metadata
override does not pre-unlock anything by design, which means it must
flow through these reuse paths intact.
Without it, the materialize layer either silently re-resolved (which
churns the lockfile) or, on the install-time check, fell back to the
spec's strict required_ruby_version metadata. Calling with_overrides
on both rebuilt SpecSets keeps the install-time behavior consistent
across resolve and lockfile-reuse paths.
https://github.com/ruby/rubygems/commit/81fb91a8b1
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Previously, any :all override called unlock_all_locked_specs_for_override
which pushed every locked spec into @gems_to_unlock. A user adding a
narrow `override :all, required_ruby_version: :ignore_upper` thus paid
for a full re-resolve that could pull unrelated dependency
upgrades/downgrades.
Make :all overrides leave the lockfile alone at converge time. They
take effect on a fresh resolution (no lockfile) or when the user opts
in via `bundle update`. Per-gem overrides retain their unlock for the
named gem since the user explicitly named the target.
https://github.com/ruby/rubygems/commit/3c95ab99e3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Phase 2.C wired overrides into MatchMetadata via Bundler.overrides, a
process-wide accessor read every time a spec answered
matches_current_metadata?. That leaked the user's Gemfile overrides
into Bundler-internal callers like SelfManager#remote_specs, where
overrides have no business: a Gemfile override could let bundle
self-update consider Bundler releases that are actually incompatible
with the running Ruby/RubyGems.
Revert MatchMetadata's matches_current_ruby? and matches_current_rubygems?
to evaluate the spec's own metadata, and add explicit
matches_current_*_with_overrides? variants. Pass overrides explicitly:
Installer#ensure_specs_are_compatible! gets them from @definition,
LazySpecification#choose_compatible reads its newly-added @overrides
attribute, and SpecSet#valid? reads @overrides set on the SpecSet.
Definition propagates @overrides to the SpecSets it constructs and to
the LazySpecs they contain. SelfManager and other callers that should
keep evaluating real gemspec metadata reach the strict path
unchanged.
https://github.com/ruby/rubygems/commit/e0ff753bbb
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Update the OVERRIDE section to cover the :all target, the
required_ruby_version / required_rubygems_version fields, and the
diagnostic shown on resolve failure.
https://github.com/ruby/rubygems/commit/ac90c83b1b
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Append the list of currently active overrides (with Gemfile location,
when known) to the SolveFailure message so a user investigating a
"could not find compatible versions" error sees what override changed
the constraint set instead of being misled by the resolver-reported
requirement.
https://github.com/ruby/rubygems/commit/10b8b53270
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Bundler::Dsl#override now records caller_locations(1, 1).first on
each Override so the originating Gemfile line can be surfaced in
later diagnostics.
https://github.com/ruby/rubygems/commit/ef73385cdc
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
matches_current_ruby? / matches_current_rubygems? now look up the
current Definition's overrides via Bundler.overrides and apply them
before checking against the runtime Ruby/RubyGems version. This
covers Installer#ensure_specs_are_compatible! and the materialize-
layer choose_compatible / SpecSet#valid? checks uniformly without
plumbing overrides through every materialization site.
When no Definition is set yet (e.g. RubyGems-side calls outside a
Bundler.definition block), Bundler.overrides returns an empty list
and the methods fall through to their original behavior.
https://github.com/ruby/rubygems/commit/afe9313b6e
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
An :all override applies to every gem's metadata, so we have no way to
know which locked entries it affects without re-resolving. Force-unlock
them all when an :all override appears so the resolver gets a fresh
chance to apply the override.
https://github.com/ruby/rubygems/commit/4f61f6813e
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Override.find_for now returns the per-gem entry when present and
otherwise the matching :all entry on the same field. This is the
single dispatch point for overrides in Definition and Resolver, so
the fallback is what wires :all into resolution and lockfile change
detection without further plumbing.
https://github.com/ruby/rubygems/commit/ef24b4eef9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Remove the temporary "not yet supported" guard so a Gemfile may write
`override :all, required_ruby_version: :ignore_upper` and similar
forms. The version: ban for :all stays — version requirements are
inherently per-gem.
https://github.com/ruby/rubygems/commit/af09f0360a
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
The per-dep loop in converge_dependencies only knows about version:
overrides via apply_override_to + matches_spec?. Metadata overrides
on direct deps were therefore invisible to lockfile change detection
and would silently no-op against an existing lock. Extend
converge_overrides_outside_dependencies to also unlock direct deps
when the override targets a non-version field.
https://github.com/ruby/rubygems/commit/fdd4c30523
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
When a spec's runtime dependencies are gathered for the resolver, its
required_ruby_version / required_rubygems_version metadata flow as
synthetic Ruby\0 / RubyGems\0 dependencies. Rewrite those before
they reach the dependency hash so per-gem overrides on those fields
take effect during resolution.
https://github.com/ruby/rubygems/commit/853e00f778
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
overrides
Extend the override DSL whitelist so per-gem metadata fields can be
declared. The :all target is rejected for now with a "not yet
supported" error so the field is purely per-gem until the next step
adds :all propagation.
https://github.com/ruby/rubygems/commit/f9e4d7bf29
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Before this change, `override "rails", version: "not a version"` was
accepted by Bundler::Dsl#override and only failed later when the
resolver tried to instantiate Gem::Requirement. Surface the error at
the Gemfile evaluation step so the user sees it on the offending line.
https://github.com/ruby/rubygems/commit/2ae83fbb4f
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Definition#apply_override_to, Definition#converge_dependencies, and
Resolver#apply_overrides each duplicated the same find expression.
Centralizing it on Override prepares for upcoming fields (and the :all
target) without repeating the predicate in every call site.
https://github.com/ruby/rubygems/commit/0c4424d5f3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
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
|
|
https://github.com/ruby/rubygems/commit/38f87aa2bc
|
|
`Pathname::SEPARATOR_PAT` should be private, but was not set to
private just due to a typo.
https://github.com/ruby/rubygems/commit/67ce6df4c9
|
|
converge_dependencies only iterates @dependencies (Gemfile-declared
direct deps), so an override that targets a gem present only as a
transitive dependency never registered as a change. With an existing
lockfile, @dependency_changes stayed false, the resolver was skipped,
and the override was a silent no-op. After the direct-dep loop,
inspect @overrides for any String target that is locked but not a
direct dep and force it onto @gems_to_unlock / @changed_dependencies
so resolution runs and the Resolver-side override hook applies.
https://github.com/ruby/rubygems/commit/a4f8f386f2
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Add an OVERRIDE section between GEMSPEC and SOURCE PRIORITY that
covers the syntax, the three operations (version spec string,
:ignore_upper, nil), and the lockfile-vs-resolution boundary.
https://github.com/ruby/rubygems/commit/275cbcaef3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
converge_dependencies compared the original Gemfile dependency
against the locked spec, so adding `override "foo", version: "= X"`
to a previously installed bundle did not register as a change.
additional_base_requirements_to_prevent_downgrades then kept
forwarding the locked version as a >= base requirement, which
intersected the override and made it a no-op. Pass overrides into
Definition.new positionally so they are available before the
constructor calls converge_dependencies, and compare each direct
dep's effective requirement (after override) to the locked spec.
https://github.com/ruby/rubygems/commit/248e1ba385
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
The Resolver-only hook reshapes deps just before PubGrub sees them,
but it does not influence the Bundler::Dependency objects fed into
Definition#expanded_dependencies. As a result the
Resolver::Package built from each direct dep keeps the original
requirement, so its prerelease policy and (in later commits) lockfile
change detection ignore the override entirely. Apply the override to
direct deps at expanded_dependencies as well so that Package metadata
and convergence see the effective requirement; the Resolver hook
remains responsible for transitive deps fetched from gemspecs.
https://github.com/ruby/rubygems/commit/6f397af4cc
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Pass the Definition's overrides through to Resolver::Base and rewrite
each dependency's requirement at the entry of to_dependency_hash so
both direct and transitive deps are reshaped before PubGrub sees them.
The hook is the same point Shopify/bundler-ignore-dependency uses,
since prepare_dependencies and the @cached_dependencies closure both
funnel through to_dependency_hash. Override#apply_to handles all
three operation kinds, so :ignore_upper and nil also start working
from this commit; integration coverage for those paths follows in
later commits.
https://github.com/ruby/rubygems/commit/93b1c5b46c
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Two override statements that target the same gem and the same field
make it ambiguous which operation should win. Raise ArgumentError
when the new (target, field) pair already exists in the recorded
overrides, leaving the previously recorded entry untouched.
https://github.com/ruby/rubygems/commit/1c90030cf9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Reject anything other than :all or a String for the target,
fields outside `:version`, and operations that are not a String,
nil, or one of the supported Symbol values (currently only
:ignore_upper). Validation runs before any Override is recorded so
that a multi-field call with an invalid entry leaves the DSL state
untouched.
https://github.com/ruby/rubygems/commit/c3b7aeb6b9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Version requirements are per-gem and have no meaning relative to the
`:all` target. Raise ArgumentError at the DSL entry point and store
nothing when this combination is given, even if other valid fields
are mixed in the same call.
https://github.com/ruby/rubygems/commit/aabf71f46f
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Switch remove_upper_bounds from a lower-bound allow-list to an
upper-bound reject-list so that operators other than <, <=, and ~>
are kept verbatim. The previous logic, inherited from
Shopify/bundler-ignore-dependency, dropped != exclusions and could
silently re-allow versions the user had explicitly pinned out
(e.g. >= 1.0, != 1.5.0, < 2.0 collapsed to >= 1.0).
https://github.com/ruby/rubygems/commit/7d73d9e035
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Introduce Gemfile-level `override target, field: operation, ...` that
collects Bundler::Override instances and forwards them to Definition
via to_definition. Validation and resolver hookup come in later
commits; this commit only wires the entry point.
https://github.com/ruby/rubygems/commit/e2fc49141c
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Reserve a slot on Definition for the upcoming Gemfile `override` DSL.
This commit only stores the data; the DSL entry point and the resolver
hookup come in later commits.
https://github.com/ruby/rubygems/commit/6fb2bf90fe
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Introduce a value object that holds a target/field/operation triple
for the upcoming Gemfile `override` DSL. apply_to dispatches on the
operation: a version spec string replaces the requirement absolutely,
:ignore_upper strips < and <= while folding ~> into >=, and nil
collapses to Gem::Requirement.default. The :ignore_upper logic is
taken from Shopify/bundler-ignore-dependency.
https://github.com/ruby/rubygems/commit/4c2cafa4e8
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
https://github.com/ruby/rubygems/commit/2a47650f64
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Bundler::LockfileParser#initialize silently accepted any string input,
including Gemfiles or arbitrary text, producing an empty parser with
no indication that the input was invalid. This caused downstream
tooling like bundler-audit to operate on unvalidated content.
Detect non-lockfile content by checking for any of the known section
headers; empty input is left untouched for backward compatibility.
Rather than raising immediately, emit a deprecation warning via
SharedHelpers.feature_deprecated! announcing that a future Bundler
version will raise LockfileError. Expose LockfileParser#valid? so
callers can branch on the result without string-matching the message.
Fixes https://github.com/ruby/rubygems/pull/8932
https://github.com/ruby/rubygems/commit/7607fe4a5d
|
|
https://github.com/ruby/rubygems/commit/cf21e9113f
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
|
(https://github.com/ruby/rubygems/pull/9501)
* Skip bundler self-checksum for unreleased bundlers
Using `Bundler.gem_version.end_with?(".dev")` only skips the own
checksum on master, but patch releases run from a source checkout
(e.g., bumping bundler/lib/bundler/version.rb to 4.0.11 on a release
branch) still record the checksum, which is environment dependent on
the local gem cache and causes frozen-lock drift on CI.
Generalize the guard with `released_bundler?`, which returns false for
any prerelease version and for bundlers loaded outside of an installed
gem location (`/specifications/`), so dev workflows don't record
self-checksums while released installs still do.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Revert "Skip bundler self-checksum for unreleased bundlers"
This reverts commit https://github.com/ruby/rubygems/commit/d4e51dd7d74c.
* Skip bundler checksum when running version:update_locked_bundler:
- Our development lockfile should not include the checksum of bundler
itself. No matter if we are doing a release.
The problem being that including a checksum in our development
lockfile create issues as some rake tasks don't run the same way on
CI.
For example, some rake tasks, build bundler.gem and some other
don't. I explained in more details the issue here https://github.com/ruby/rubygems/commit/2c40b8d563f2
This commit here is motivated by the fact that when the release
manager runs `version:update_locked_bundler`, if a
`bundler-<VERSION>.gem` exists on its system (e.g it previously ran
`rake bundler:install`), then the lockfile will include a checksum
entry.
---------
https://github.com/ruby/rubygems/commit/ee558f2f9d
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Edouard CHIN <chin.edouard@gmail.com>
|
|
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
|
