News for hackers. Stuff that matters.

A comment on The Rails Doctrine. Parent comment

Re:The Rails Doctrine by troels on Tuesday January 19, 2016 @02:24PM (#10933205)
The thing about gem churn is somewhat true, BUT that is a problem in any open source eco-system that I've seen so far. And in fact I think Rails fares much better in this area than most others. There are a lot of very high quality gems out there that are actively maintained and play well together. Contrast that to the cesspool that is Wordpress plugins.
[ Parent | on HN ]
Re:The Rails Doctrine by vinceguidry on Tuesday January 19, 2016 @02:40PM (#10933350)
My solution for this is to never specify gem versions in my Gemfile and once a month or so do bundle update. Much easier to fix one gem update problem at a time than to try to fix 6 all at once.
[ Parent | on HN ]
Re:The Rails Doctrine by methyl on Tuesday January 19, 2016 @03:37PM (#10933804)
The problem is when you won't notice something went wrong with the update.
[ Parent | on HN ]
Re:The Rails Doctrine by briandear on Tuesday January 19, 2016 @04:50PM (#10934359)
You will if you use proper TDD.
[ Parent | on HN ]
Re:The Rails Doctrine by rtpg on Tuesday January 19, 2016 @08:16PM (#10935385)
What's true of all bugs? It passed all the tests

I don't here about people being bug free with TDD ( though significantly less bugful)

Obviously all about tradeoffs, but my impression is that if a third party lib needs a major version update, the time changing the version in your requirements is dwarfed by the time needed to investigate generally

[ Parent | on HN ]