3 ms·

Is this an issue for people? I have bundle update as a part of my build/release process, if things break, I either update, or freeze the version. How do other

by Volpe 15y ago

Is this an issue for people? I have bundle update as a part of my build/release process, if things break, I either update, or freeze the version. How do other people deal with this?

jwilliams 15y ago
Doesn't keep me up at night, but it was something I was doing manually and I thought better off scripted. Even with fuzzy/handwave "~> 1.1.1" specifications you can end up off the most current version. I've got a handful of projects on the go and as a rule I don't like to let them go stale.
- Volpe 15y ago
  but, just simply leaving the version number blank, "bundle update" will get the latest. correct?
  - beilabs 15y ago
    Yes, that's correct. Personally I always assign the working version numbers to the Gemfile. What happens in say a years time when you're meant to come back and maintain the site? New versions could mean a drastically broken system and you won't be maintaining a contracts codebase if you are not getting paid to do so.
    - Volpe 15y ago
      The .lock file will have the versions that are currently bundled, so you can always check what versions are bundled there. But I guess that requires a bit of messing around, where as what you do seems quite straight forward.
      - beilabs 15y ago
        Yes but if the repository is cloned with a lock file, when you bundle install, the lock file is then updated with your new gem versions if you have not specified a specific gem version number.
        Volpe 15y ago
        not to labor the point. But the lock file is in the repo, it doesn't matter if it's updated, there is a version in the repo.
sandGorgon 15y ago
if a newer version breaks, then I pull the older version into a local directory ("vendor/mine") and use :path directive in my gemfile
- nixme 15y ago
  Why not just put an explicit version number directly in the Gemfile. Seems easer than vendoring the gem and bloating the repo (unless you're worried about old versions being yanked from rubygems).

by Volpe 15y ago

Is this an issue for people? I have bundle update as a part of my build/release process, if things break, I either update, or freeze the version. How do other people deal with this?

jwilliams 15y ago

Doesn't keep me up at night, but it was something I was doing manually and I thought better off scripted. Even with fuzzy/handwave "~> 1.1.1" specifications you can end up off the most current version. I've got a handful of projects on the go and as a rule I don't like to let them go stale.

Volpe 15y ago
but, just simply leaving the version number blank, "bundle update" will get the latest. correct?
- beilabs 15y ago
  Yes, that's correct. Personally I always assign the working version numbers to the Gemfile. What happens in say a years time when you're meant to come back and maintain the site? New versions could mean a drastically broken system and you won't be maintaining a contracts codebase if you are not getting paid to do so.
  - Volpe 15y ago
    The .lock file will have the versions that are currently bundled, so you can always check what versions are bundled there. But I guess that requires a bit of messing around, where as what you do seems quite straight forward.
    - beilabs 15y ago
      Yes but if the repository is cloned with a lock file, when you bundle install, the lock file is then updated with your new gem versions if you have not specified a specific gem version number.
      - Volpe 15y ago
        not to labor the point. But the lock file is in the repo, it doesn't matter if it's updated, there is a version in the repo.

sandGorgon 15y ago

if a newer version breaks, then I pull the older version into a local directory ("vendor/mine") and use :path directive in my gemfile

nixme 15y ago
Why not just put an explicit version number directly in the Gemfile. Seems easer than vendoring the gem and bloating the repo (unless you're worried about old versions being yanked from rubygems).