3 ms·

>Unless I've tested my code with a version of a library, I can't know if it works. Is this not a problem with other versioning systems? Like Apache Commons?

• ilammy 5y ago
  Of course, you have to test your code. But testing is not a good way to demonstrate absence of unknown bugs and incompatibilities. You don’t know that an unknown issue exist until you have a test that exercises that particular code path which triggers an issue. Semver looks like a promise “upgrade from 1.5.0 to 1.17.5 is always compatible” but this promise can still be broken, with probability dependent on the depth and breadth of your dependency tree. It’s frustrating to see this promise broken when you find an issue, write a test, downgrade the dependency to semver-compatible version, and the test passes.
  • stubish 5y ago
    The great thing about a promise to be compatible is it means if it does break your build you know where to report the bug, and help out the developers who were trying to make a compatible release for your benefit. And that doesn't have anything in particular to do with semver at all. It is just about your use case and if you need to pin your dependencies or not, and the downsides to either approach.
• simiones 5y ago
  The problem is that I can release LibA with a dependency on LibC ^1.2.3. I also have a dependency on LibB, which in turn depends on LibC ^1.3.5. We will accept that LibA works with LibC 1.2.3 perfectly, and LibB works with LibC 1.3.5 perfectly. But nothing guarantees that LibA will work with LibC 1.3.5, and this is where the problem starts. In contrast, if LibA, LibB and LibC are all bundled into a Lib-Commons, I have good reasons to think that depending on Lib-Commons 2.4.6 is not going to produce unexpected incompatibilities between Lib-Commons.LibA and Lib-Commons.LibC.