5 ms·

Semver always seems utopic to me. Unless I've tested my code with a version of a library, I can't know if it works. Even if they are religiously following Semve

Semver always seems utopic to me. Unless I've tested my code with a version of a library, I can't know if it works. Even if they are religiously following Semver, there is always the possibility that they have a bug that happens to affect my library. Automatically picking up some library versions based on a hope that people adhered in the same way to Semver and that they don't have any bug-level incompatibilities seems highly optimistic. This is one of the main reasons I hate this trend of small libraries: I don't want to have a complex web of dependencies that I am the first person to ever test in this particular version combination. Give me Apache Commons any day of the week, with a single unified version for hundreds of classes that I know for sure work together among themselves.

tikkabhuna 5y ago
I like Semver. Not because it guarantees that a minor bump won't break anything, but that the maintainers expect it shouldn't. If I need to bump a version with Semver, I can estimate how long it will take. Going from log4j 1.2.17 to 2.17.1 will be bigger than going from 2.16.0 to 2.17.0. And 2.17.0 to 2.17.1 should be easy. I completely agree with your last paragraph, though. I'll take a collection of utilities from a well known organisation over many tiny dependencies any day.
- simiones 5y ago
  Absolutely, Semver is a good idea as a way of organizing your software's versions. But basing your pacakge manager on the specification of Semver seems like a bad idea to me - though it is extremely popular in the industry currently (NPM, Cargo, go mod, and others support it).
  - WorldMaker 5y ago
    It's tough to remember that the "sem" in "semver" stands for "semantic" and implies "meaningful to other software developers". I understand why we like to try to automate it, but aspects of it were intentional rejections of automated version numbers in the first place and it feels like a cycle of automating things, finding failures in them when automated, and trying to remind ourselves why we shouldn't just automate every aspect of our jobs. Sometimes you need the "semantics", the human judgment calls.
moss2 5y ago
>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.
ReleaseCandidat 5y ago
That's why using package sets (or whatever you want to call them) is a necessity with such packages like crates. The set of 'most important' (whatever that means ;) packages in versions that are _tested_ to work together. So that you do not end with broken dependencies like needing package A in a version <d and >d at the same time. Haskell 'does' this with their LTS and nightly package sets: https://www.stackage.org/snapshots https://www.stackage.org/snapshots Without such a curated set of packages I've eventually run into unresolvable dependencies with ever package manager and language used by me.
pornel 5y ago
Just remember when adding `apache-commons` crate to your project, use `apache-commons = "1.2.17"`, not `apache-commons = "1"` :)
- ReleaseCandidat 5y ago
  Works as long as none of the transitive dependencies needs `apache-commons /= "1.2.17"`.
  - pornel 5y ago
    It could, but in my experience (using it for 7 years now), it's rarely a problem in the Rust/Cargo ecosystem. That's because in Cargo this doesn't mean the exact version, but only a minimum version (like "^1.2.7" in npm). Different versions will be unified automatically (or even whole dependencies duplicated if they differ by semver-major). You can get a conflict only if someone very specifically required an incompatible lower version, like "<1.2.17" or "=1.2.16", and only if the crate with that requirement could not be avoided by choosing different versions of dependencies. In practice such locked version ranges are used rarely and temporarily, because they are known to be disruptive.
epage 5y ago
For me, semver isn't perfect but its good enough. At least for my experience in the Rust community: - You can trust people to not break things. For the unsusual cases, people are quick to respond by yanking. - Once people hit 1.0, they rate limit their breaking changes to be less disruptive The nice thing about small libraries is each incompatible upgrade is a smaller step which makes it easier to take on. I've seen large code bases struggle to adjust to large breaking changes and hold off until it becomes business critical.

tikkabhuna 5y ago

I like Semver. Not because it guarantees that a minor bump won't break anything, but that the maintainers expect it shouldn't. If I need to bump a version with Semver, I can estimate how long it will take. Going from log4j 1.2.17 to 2.17.1 will be bigger than going from 2.16.0 to 2.17.0. And 2.17.0 to 2.17.1 should be easy. I completely agree with your last paragraph, though. I'll take a collection of utilities from a well known organisation over many tiny dependencies any day.

simiones 5y ago
Absolutely, Semver is a good idea as a way of organizing your software's versions. But basing your pacakge manager on the specification of Semver seems like a bad idea to me - though it is extremely popular in the industry currently (NPM, Cargo, go mod, and others support it).
- WorldMaker 5y ago
  It's tough to remember that the "sem" in "semver" stands for "semantic" and implies "meaningful to other software developers". I understand why we like to try to automate it, but aspects of it were intentional rejections of automated version numbers in the first place and it feels like a cycle of automating things, finding failures in them when automated, and trying to remind ourselves why we shouldn't just automate every aspect of our jobs. Sometimes you need the "semantics", the human judgment calls.

moss2 5y ago

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

ReleaseCandidat 5y ago

That's why using package sets (or whatever you want to call them) is a necessity with such packages like crates. The set of 'most important' (whatever that means ;) packages in versions that are _tested_ to work together. So that you do not end with broken dependencies like needing package A in a version <d and >d at the same time. Haskell 'does' this with their LTS and nightly package sets: https://www.stackage.org/snapshots https://www.stackage.org/snapshots Without such a curated set of packages I've eventually run into unresolvable dependencies with ever package manager and language used by me.

pornel 5y ago

Just remember when adding `apache-commons` crate to your project, use `apache-commons = "1.2.17"`, not `apache-commons = "1"` :)

ReleaseCandidat 5y ago
Works as long as none of the transitive dependencies needs `apache-commons /= "1.2.17"`.
- pornel 5y ago
  It could, but in my experience (using it for 7 years now), it's rarely a problem in the Rust/Cargo ecosystem. That's because in Cargo this doesn't mean the exact version, but only a minimum version (like "^1.2.7" in npm). Different versions will be unified automatically (or even whole dependencies duplicated if they differ by semver-major). You can get a conflict only if someone very specifically required an incompatible lower version, like "<1.2.17" or "=1.2.16", and only if the crate with that requirement could not be avoided by choosing different versions of dependencies. In practice such locked version ranges are used rarely and temporarily, because they are known to be disruptive.

epage 5y ago

For me, semver isn't perfect but its good enough. At least for my experience in the Rust community: - You can trust people to not break things. For the unsusual cases, people are quick to respond by yanking. - Once people hit 1.0, they rate limit their breaking changes to be less disruptive The nice thing about small libraries is each incompatible upgrade is a smaller step which makes it easier to take on. I've seen large code bases struggle to adjust to large breaking changes and hold off until it becomes business critical.