Clever Geek Handbook

Should I put gem versions in my Gemfile?

So far I just use the gem name and don't mention the version number, this is good practice (pros: gems keep auto-updating, cons: app might break)

if a version number is recommended, what are the standard practices for using it?

EDIT - I just did a "bundle show" and it shows about 30+ gems, although I only have 6 gems listed in the Gemfile, I guess the rest are the main gems that are set when the app is created, so how block them or will I just leave them intact?

+3


source to share


5 answers


I think yes . Coz in the early days I had so many problems with gemstones that update on their own rather than backward compatible.

This usually happens when you switch from one major version to another, for me its rails 2.x - 3.x



So the bottom line is useful to have the versions in the Gem file.

HTH

+2


source


I thought so too at the beginning.

But then there would be some updates that didn't quite match what I coded, or there would be incompatible changes that cause the function to stop working.

happened to me at least twice that I would update the gem the moment the stone was push and I was one of the first to see it all break due to some bug that was not fixed During the push. So you are trying to debug and it won't work. From then on, I would lock the problematic gems and only update them when that's the only thing I do and make sure the functionality stays the same.



It is advisable to use versions that you know work.

After that you can use gemnasium to track gems

+2


source


My suggestion would be YES .

The reason is that I view external dependencies as potential moments of violation, since they are somewhat beyond my control; any change that is an external dependency that is not initiated by me is a potential failure.

Since software development is already complex, I firmly feel that both constraining and controlling external dependencies work in our best interest.

The fewer surprises, the easier it is to maintain the code.

NTN

+2


source


One of the goals of the binder is to bind your dependencies to specific versions. So, first, bundle

after adding a gem to the Gemfile, the gems will be bound to specific versions. You must specifically do bundle update <gemname>

to make an update on a specific stone. Simply bundle update

(which updates all gems to the most recent compatible versions) pretty much defeats the purpose of bundler and should be avoided.

who said I think Gemfile should only list versions if it has a specific reason. Example. You want to use rails version 3.2.8 or use ruby-net-ldap 0.0.1 because 0.0.2 breaks some functionality.

+2


source


It is good to use exact version numbers. You can probably always just block it to a major version, or never specify any version, and that's okay, but if you really want that subtle level of control and 100% sure of your program when run on other machines , use the exact version numbers.

I've been in situations where the exact version number was not specified, and when I or someone else did bundle install

, the project broke because it switched to a newer version. This can be especially bad when deploying to production.

Bundler

blocks your gem stats, but if you say you are just using the main set then it blocks that.

Also, if not Gemfile.lock

, deploying the code for production would be a major issue because as dependencies and gem changes might change.

+1


source






More articles:


All Articles