Skip to content
This repository has been archived by the owner on May 10, 2019. It is now read-only.

Commit

Permalink
Specify that we should lock on specific gem versions
Browse files Browse the repository at this point in the history 
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
@jystewart
jystewart committed Aug 9, 2012
1 parent a198cb1 commit b17b34a
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions ruby.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down

3 comments on commit b17b34a

@timdiggins
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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!

@jystewart
Copy link
Contributor Author

@jystewart jystewart commented on b17b34a Dec 2, 2012 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timdiggins
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.