Skip to content
Browse files

Specify that we should lock on specific gem versions

We aren't confident that all of our dependencies will follow sensible versioning practices and so will need to do some review of all new versions. Locking them down protects against minor changes creeping in unintentionally and/or exposing ourselves to new security issues this way.
  • Loading branch information...
1 parent a198cb1 commit b17b34a361daf705818b648a5e06ad9fe6f2915c @jystewart jystewart committed Aug 9, 2012
Showing with 8 additions and 0 deletions.
  1. +8 −0
@@ -4,6 +4,14 @@
- Write for Ruby 1.9.
+- Lock dependencies in Gemfiles to specific versions.
+ ```gem 'rails', '3.2.7'```
+ not
+ ```gem 'rails', '~> 3.2.7'```
- Use soft-tabs with a two-space indent.
- Keep lines fewer than 80 characters.

3 comments on commit b17b34a


@jystewart why do you think this is important? Isn't this what Gemfile.lock is for? Gemfile is for semantic (major/minor) dependency not exact locking dependency (major/minor+patch).

PS - stumbled on this in a forked styleguide and wanted to ask you direct!


Thanks for the response! I can see your reasoning, and probably makes sense on GDS but less so on the smaller teams with less reviewers (where just "a file is changed" is the level of review). Then, it's useful to have the distinction between Gemfile.lock being updated on its own (hopefully as a single commit accompanied by "updating versions to the latest allowable") and then Gemfile being updated as well (usually with bringing in a new or updated dependency and maybe in a commit bringing in additional tests/functionality). (of course this does require careful dependency expressing in Gemfile, e.g. gem 'rails', '~> 3.2.7' rather than gem 'rails', '~> 3' !.

Maybe the real take out is - don't just adopt someone else's styleguide (etc) without considering (a) your own needs and (b) in any case the difference in team size/mandate.

Please sign in to comment.
Something went wrong with that request. Please try again.