This has expressed the ideas in my head far better than I could. When I first started to work with Rails in many projects I just dumped all of the gems I wanted to use in my Gemfile. I quickly learned that a simple bundle update could fuck my shit up pretty badly by having gems change APIs, remove features or both.
Since then I always specify the exact versions of my gems or in cases where the gem authors are known to be comptent use the "~>" operator. I find it to be stupid though much like the article states, why are newer versions making my life harder when they are supposed to be better?
I personally think it's better to break backwards compatibility if you're removing or changing something that was bad in the first place. Otherwise, there is no need, and thus it never breaks. Much like in the case of your list of non breaking programs.
> I personally think it's better to break backwards compatibility if you're removing or changing something that was bad in the first place.
This is the false dichotomy that I want to dispel. You can remove/change bad things while maintaining backwards compatibility in most cases! It just takes a little bit of extra glue code!
Since then I always specify the exact versions of my gems or in cases where the gem authors are known to be comptent use the "~>" operator. I find it to be stupid though much like the article states, why are newer versions making my life harder when they are supposed to be better?