3 ms·
There is also no way to really know what a breaking version is. Every single update must be tested to make sure it really isn’t breaking. I have had cases where
by PurpleFoxy 6y ago
There is also no way to really know what a breaking version is. Every single update must be tested to make sure it really isn’t breaking. I have had cases where a library fixed a bug and it turns out we rely on the existing behaviour so the bug being removed is a breaking change.
- larusso 6y agoYes behavior is the other huge problem. I cover this mainly with integration tests. And whatever wasn’t covered by these specs is not part of the API. But there lies the issue. What if the developer forgot to add a spec or worth the tests returned false positives because of test setup issues. Or also one of my favorite issues are when dealing with rest APIs. They get flagged deprecated removed etc without remorse that it means that large parts of old software libraries are practically broken without actually being broken. Catching these means running active nightly builds etc if you don’t actively maintain the library on a regular basis. The switch from GitHub to use main as the default branch name for repositories brought a lot of issues with one gradle plugin I wrote because I hardcoded (yes it was my fault here) the value to be “master” which for years was the norm that every repo had one. In hindsight it was a clear oversight from my side because one could have removed the master branch before obviously.