[kinyoklion]

Resolve dependencies only to gem versions that have been public for at least seven days, using Bundler's cooldown.

• No pinning and no lockfile: we still get the newest version matching each constraint, just not one published in the last week
• launchdarkly-server-sdk is exempt, so a constraint bump right after our own release still resolves
• Requires Bundler >= 4.0.13, so CI pins Bundler to 4.0.19 on the setup-ruby step
• Contributors on Bundler 2.x are unaffected — the setting is silently ignored, so they simply resolve to the newest versions

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Follow-up to #34: the RuboCop 1.90.0 breakage that PR works around would have been held out of CI by this cooldown.

Implementation details

How it works

source "https://rubygems.org", cooldown: 7 makes Bundler consult the per-version created_at timestamp in rubygems.org's v2 compact index during resolution and pass over any version younger than the window. Versions whose source does not expose created_at (private registries, pre-v2 entries) stay resolvable, so this never silently blocks a resolution. --cooldown 0 / BUNDLE_COOLDOWN=0 is the escape hatch when the newest release is exactly the one you want, e.g. a security fix.

Why the second source block

Cooldown is stored per remote URI (Bundler::Source::Rubygems#remote_cooldowns), with no per-gem option, and a second source block for the same URI does not get its own value. Naming the registry's index host gives a distinct remote that can carry cooldown: 0:

source "https://index.rubygems.org", cooldown: 0 do
  gem "launchdarkly-server-sdk"
end

Without this, cooldown: 7 fails resolution outright today: our gemspec requires launchdarkly-server-sdk ~> 8.15, 8.15.0 was published 2026-08-20, and no older version satisfies the constraint, so every candidate is inside the window.

The source contains the following gems matching 'launchdarkly-server-sdk (~> 8.15)':
  * launchdarkly-server-sdk-8.15.0-java
  * launchdarkly-server-sdk-8.15.0
... version solving has failed.

Exempting it is also the right policy: we publish that gem, so it is not the untrusted-third-party case cooldown defends against.

Verification

Ran locally in containers against this branch (no lockfile, Bundler 4.0.19):

Runtime	Result
CRuby 3.4.10	rubocop 1.90.0 (available in 6 days), resolved 1.89.0 instead; launchdarkly-server-sdk 8.15.0 resolved; 73 examples 0 failures; 15 files inspected, no offenses
JRuby 10.0.6.0	same, including the -java platform gem through the exempt remote

Also confirmed Bundler 2.6.9 (Ruby 3.4's default) resolves the same Gemfile without error, ignoring the cooldown: option.

Alternatives considered

• cooldown: 3 with no exemption: shorter window, and still breaks for three days after each of our own SDK releases.
• Commit a Gemfile.lock and let Dependabot bump it with a cooldown: gives an auditable dependency history, but pins a library to specific versions and stops testing against the newest supported ones.
• bundle config set cooldown / BUNDLE_COOLDOWN in the CI workflow only: leaves local bundle install unprotected, and cannot express a per-source exemption.
• The bundle-safe-update gem (pre-dates Bundler's feature): a low-adoption single-maintainer dependency, which is itself supply-chain risk.

Link to Devin session: https://app.devin.ai/sessions/47847578334a4bd497c24e3859630cd2
Requested by: @kinyoklion

---

Note

Overview
CI and local installs now resolve gems from rubygems.org only if the version has been published for at least seven days, using Bundler’s cooldown on the main Gemfile source—without adding a lockfile or pinning versions beyond existing constraints.

launchdarkly-server-sdk is pulled through a second source (index.rubygems.org with cooldown: 0) so first-party releases still resolve immediately; the PR description notes this is required because the current ~> 8.15 constraint would otherwise fail resolution.

GitHub Actions pins Bundler 4.0.19 on ruby/setup-ruby in the shared CI composite action and the Windows workflow so cooldown is honored in CI. CONTRIBUTING.md documents the behavior, the Bundler 4.0.13+ requirement, and --cooldown 0 for urgent updates.

^{Reviewed by Cursor Bugbot for commit a2cca54. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6f0f1fb. Configure here.}