4 ms·

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

deleted 5y ago
[deleted]
kinduff 5y ago
Learned this the hard way. No matter the change or version, I always try to double check both CHANGELOG and the commits.
- montblanc 5y ago
  I think tests should have caught that one but I agree.
  - henry700 5y ago
    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.
    - montblanc 5y ago
      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.
      - henry700 5y ago
        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.
kortex 5y ago
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.
- ljm 5y ago
  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.
  - Railsify 5y ago
    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.
- Railsify 5y ago
  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.

deleted 5y ago

[deleted]

kinduff 5y ago

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

montblanc 5y ago
I think tests should have caught that one but I agree.
- henry700 5y ago
  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.
  - montblanc 5y ago
    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.
    - henry700 5y ago
      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.

kortex 5y ago

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.

ljm 5y ago
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.
- Railsify 5y ago
  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.
Railsify 5y ago
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.