Hacker News Reader

Comment by Railsify | Hacker News Reader

Semantic Versioning does not mean you can update without reading the changelog. Blame here remains with the developer who updated without reading the changelog.

View on HN

Do you or your team review every item of every changelog of every dependency in your stack (recursively for their dependencies) for every minor update, and/or 100% coverage for all of your assumptions of how they are used?

Sure it was a mistake by OP in TFA but it's an honest mistake any of us could make. And it's a really Bad Move by the Mongoid devs. It'd be a bad move in 1.2->1.3, but by 7.3? I'd just be like "whelp, this is how this function behaves now in perpetuity, I guess just document that it has different semantics than AR" even if an 8.0 was released. This is the kind of change which causes really subtle bugs. It's rarely worth it. Just introduce .chain_or() or something.

I think you're trying to make the case sound a bit more absurd than it really is, in terms of recursively scanning dependencies and checking for 100% coverage for all assumptions.

It's really just as simple as going to the release notes and seeing if there's a mention of breaking changes or deprecations. If no such thing is mentioned then you're fine, otherwise you go and see if that change affects you at all and just take a little bit more time to test the upgrade. This has been standard practice at plenty of places that I've worked.

It also doesn't mean that it makes the change a particularly good one, but I don't think I can make a bunch of OSS maintainers responsible for my own failure to review an upgrade and test it before rolling it out. In those terms, there is some culpability both with the maintainers and with the library users.

This is well stated. It's about taking your fair share of responsibility, as engineering we bend code to our will, this includes reading the code of opensource packages.

Yes, I generally scan the changelog and look at the diff on github from the previous version. Not doing so is penny wise and pound foolish, the risk to brand and the risk of downtime is too great to install a crypto miner, or a vulnerable log4j version, etc.

Learned this the hard way. No matter the change or version, I always try to double check both CHANGELOG and the commits.

I think tests should have caught that one but I agree.

Not if you follow the One True Way of Unit Testing (tm) where the Mongoid lib would have been mocked away, and the test would pass :)

Integration tests might've done the job here.

You dont mock the db layer, i dont do that at least, hell no. Let the db be hit, check that the records it returns make sense. Thats how I roll at least.

Didn't want to aim at you with the reply, just remembered the collective delusion of 100% coverage unit testing zealots and how this would ironically fail to catch this.

You'd be surprised how far people go to shoot themselves in the foot.

Reply on news.ycombinator.com