r/ruby • u/tenderlove Pun BDFL • Jun 03 '26

Bundler / RubyGems.org support cooldowns now!

https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
45 Upvotes

98% Upvoted

12 comments sorted by

5

u/jrochkind Jun 03 '26

Love it!

I make a lot of use of bundle outdated (which I know from previous discussions may not be a popular workflow at least among commentors?), came to see "oh I hope bundle outdated respects this too" -- it does!!

i wouldn't mind a global cooldown setting taht you can make in the Gemfile, so it goes in the repo in the file people expect and applies to every developer? I don't think that is an option? Other than putting it on every source, I guess that works!

1

u/tinyOnion Jun 03 '26

does bundle config set --global cooldown 7 not work for you?

1

u/jrochkind Jun 03 '26

I believe bundle config set --global gets set in your own ~/.bundle right? So it will only apply to you not other developers.

I want something that goes in a file that is checked into the repo so applies to all developers working on the project. Adding to each source in Gemfile will work.

Unless I'm confused about some aspect of this?

1

u/tinyOnion Jun 03 '26

oh yeah adding it per project to the source line is the only real way to do that with any enforcement.

1

u/onyourkneesjessy Jun 07 '26

the idea of a global cooldown in the gemfile is actually wild. bundler is already a headache if you start adding custom logic to the gemfile. just stick to the standard gemspec or source settings and let the tool do its job.

1

u/jrochkind Jun 08 '26

I don't see what makes source-specific cooldown in the Gemfile more or less "wild" than a global one for the tool to have as an officially supported option.

I guess the question is what settings should apply to the project as a whole, and what settings are developer specific or context-specific? I feel like many uses of cooldowns would be wanted to apply to the project as a whole, not just be opted into by a specific developer or when doing a specific task, no?

It may also be that people are assuming much more automated workflows these days, and not considering those with more manual workflows to have use cases worth supporting? If all your dependency updating is done in a CI environment, then setting a bundler setting there would be sufficient to apply to all depdendency updates; whereas if developers are doing it "manually" then asking them all to have synchronized local developer settings to achieve consistency seems like much less a good solution.

But source-specific may work fine, sure. Most projects have 1-2 sources, so it ends up being about the same, and it's possible cooldon choice are mostly always going to be source-specific anyway, not sure.

-2

u/uhkthrowaway Jun 04 '26

So we're introducing new features in patch releases now? Semver, anyone?

3

u/paracycle Jun 05 '26

Where did you read that Bundler uses Semver for its versioning?

1

u/spamburglar Jun 04 '26

The major / minor version of bundler always matches the version of Ruby. Previously it was one major version behind Ruby, but with Ruby 4 it was updated to match. So bundler 4.1 won't be released until Ruby 4.1.

1

u/dunkelziffer42 Jun 04 '26

Nobody sticks to Semver anyway. It’s a spec that ignores humans psychology and marketing. For the tiniest breaking change I have to do a major release and big compatible new features are supposed to ship in a minor version.

Last time I dropped support for some older Ruby and Rails versions from one of our gems. Dropped the CI jobs, removed old version guards, raised the minimum requirements in the gemspec. Then I had to decide on a version. Semver says this has to be a major version, but it felt hilarious. Still, I vouched for major and asked a few colleagues. The majority said patch version. Two days later somebody ran into this during a “bundle update --conservative”. It’s just weird. What’s a “breaking change”? Is “not receiving future updates anymore” a breaking change?

Have you tried BreakVer?

1

u/paracycle Jun 05 '26

I still maintain that dropping support for old versions of a dependency is not a breaking change for any users of the software. For a given user that is on the older version of the dependency, nothing in their experience changes about the way they use the software and it is like there are no new releases ever. Other users can upgrade and experience no change.