0

Why should one care about specifying gem version at all if bundler detects Ruby version and manages to get the latest release to match that version. If I'm not a fond of newer version personally, I would disable incrementing with ~> 1.4.4 and in other cases I'd let bundler manage stuff with putting gem name into Gemfile without any argument

Anton Semenichenko
  • 354
  • 5
  • 14
  • 1
    Because updating your bundle will update all those loosely specified dependencies and may introduce multiple breaking changes at once. Dealing with one broken dependency is annoying - dealing with 5 at once is true dependency hell. – max Sep 10 '20 at 21:53
  • 1
    For example, you may need to pin versions for compatibility purposes: https://stackoverflow.com/a/60491254/3784008 – anothermh Sep 10 '20 at 23:52

1 Answers1

3

The approach you are suggesting - start with the latest version and pin if problems are experienced - works fine for projects that are 1) actively maintained and 2) tolerant of breakage.

Now imagine you have to deliver this project to a customer who then will run it for a year or longer and you won't be there to support it. In this case simply getting the latest release of all dependencies is not necessarily the best strategy. Maybe you would proactively specify major versions of all of your important dependencies instead. Potentially even lock to minor versions which does give more stability at the cost of missing security updates/bug fixes.

D. SM
  • 13,584
  • 3
  • 12
  • 21
  • It feels like nobody's keeping in mind locked Ruby version, this, in my earlier thoughts, was a lock point, but now I understand that that such practice is not reliable, as someone can potentially merge an update to all earlier gem release versions and the whole thing might blow up. – Anton Semenichenko Sep 11 '20 at 09:20
  • 2
    Locking Ruby version doesn't make the library dependency versions locked. – D. SM Sep 11 '20 at 15:29