4 ms·
Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more t
by notimetorelax 5y ago
Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? I think this example exposes the futility of semantic versioning.
- cozzyd 5y agoYeah, PROJ handled this correctly, introducing a new header file and eventually deprecating the old one after a while, making it hard to do the wrong thing. But for some reason pyproj must have kept the same interface across the breaking change?
- notimetorelax 5y agoIn general I agree but I'm making an argument that a non-functional change for you may be a functional change for your users.
- dragonwriter 5y ago> Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? You need to investigate the reasons for a major version change before updating the dependency and running tests any time one occurs, to see if any documented behavior you are expecting has changed.
- Helmut10001 5y agoIndeed, this was entirely our fault and as I said, we should have correctly pinned, at least the major version. Our tests did not catch the specific issue, because all code worked - just the output looked scrambled. There are tests that could catch this issue, but we did not anticipate it and therefore had no tests prepared.
- berkes 5y agoA the the time of encountering, I dislike such issues. Stress, downtime, frustration. But a few weeks later, I love them. They are a great opportunity to learn how well a test suite is setup. How it can be improved, cleaned up, refactored, or just kept the same.