Hacker News new | past | comments | ask | show | jobs | submit login

It happens.

(Without meaning to sound callous to folks who have been reduced to firefighting this week: with sane practices on applying updated libraries to production, it happens to other people.)




This is why I fix the versions on ALL my gems to a known good version. Updates can only happen by changing that version in my source. Tests will be run after that, of course. I'm pretty sure it's standard practice now, but I can't believe there was a time when I didn't do this.

Just 2 days ago, a new version of authlogic was released that accidentally broke 2.3.5 compatibility. And that's a respected and widely used gem. It happens. Also, many gems are starting to deliberately break rals 2.3 compatibility - their newer versions are rails 3 only. Not to mention that gem authors sometimes deprecate and then obsolete some interfaces. So if you're not fixing your versions yet, and you don't have "sane practices" for updating them, it's time to start.


This is the main reason I think we need distributions (in the Debian sense) of gems. It needs to be ok for the gem authors to go ahead and break compatibility if they need to. App maintainers also need to know that they are safe unless they choose to opt in to breaking changes. A distribution would act as the go-between.

If you've got sane library management processes, you're pretty much safe, but that's a huge amount of wasted effort - everybody has to figure it out for themselves. Right now, it's downright dangerous relying on upstream gems directly unless you know exactly what you're doing, and a distribution layer would let everyone share a common knowledge about which gem versions go well together.

It would also give a handy insertion point for backporting security fixes, which currently doesn't happen very often.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: