4 ms·

I maintain a batterie of libraries for my company. Managing dependencies is one of the hardest part even with internal only libraries. Our major pain-point is t

I maintain a batterie of libraries for my company. Managing dependencies is one of the hardest part even with internal only libraries. Our major pain-point is the dependency towards 3rd party software and dealing with semver. Semver is not really hard to understand it’s just hard to execute as the developer is executing the rules. So for instance if I create a library/plugin etc which wraps around a tool, would it be a breaking change when the software stops supporting a specific version of the wrapped tool even though the internal API stayed the same (this happens a lot for me with gradle plugins which suddenly decide to not being compatible with the version of gradle I use). I would say yes but for larger dependency trees this becomes a nightmare. For our internal unity3d libraries we decided to not count the supported Unity versions as part of the semver version. The other option would be to have special library packages for each version of unity similar to how the Spock testing framework[1] deals with groovy. For this option we don’t have enough engineers at my company. [1] https://github.com/spockframework/spock https://github.com/spockframework/spock [edit] spelling

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 ago
  Yes 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.

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 ago
Yes 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.