3 ms·

A rust program depends on various libraries. It releases a specific version. Not pinning to specific dependencies for that specific version is weird for everyon

by rtpg 2y ago

A rust program depends on various libraries. It releases a specific version. Not pinning to specific dependencies for that specific version is weird for everyone who gets that program outside of their OS distribution package manager! I release foo 1.2.3 as a package, when doing it depending on bar 4.5.6. Perhaps foo still compiles with bar 4.5.2 or 4.6.8... but that's _not_ foo 1.2.3 right? And if there are bug fixes in some of those but not others, if I had my deps set up to just package with "bar 4.x" , suddenly I'm getting bug reports for "1.2.3" without a real association to "the" 1.2.3. I'm saying this, perhaps this is as easy as having two sets of deps (like deps for repackagers, deps for people wanting to reproduce what I built)... but if a binary is being shipped _not_ being explicit about the exact dependencies used is upstream of a whole lot of problems! Is there a great answer from OS distro package managers for this? Is the thing that should happen here be that there's a configure step in rust builds that would mess around with deps based on what you have?

LtWorf 2y ago
If your library changes API all the time, do you think it's a good library? Do you rewrite every API call in your software every time you bump dependencies? Do you think that a library that changes API very often and thus remains insecure because bumping it breaks the program should be running on people's computers?
- zozbot234 2y ago
  > If your library changes API all the time, do you think it's a good library? If it has a 0.x.y version number? Yes, that's what 0.x means to begin with. In fact Rust/cargo provides a stricter interpretation of semver than the original, which allows you to express guarantees of API stability (by keeping the minor version number fixed) even in 0.x-version projects.
  - LtWorf 2y ago
    If it has a 0.x version number it should be good policy to not use it.
- rtpg 2y ago
  Why do you think libraries get any releases at all? Software A and B depend on C (version V). A has a bug that gets fixed by shipping with C version V+1. B unfortunately has a latent bug that appears when shipping with C (version V+1). You’re now going to have to do a bunch of work, outright not ship stuff, or even introduce bugs because of this policy! Nobody wants buggy libraries, and in this example it’s not the library’s fault (B might just be misusing C, or in fact compensating for a bug). Reading through these threads I’m much more empathetic to the software bill of materials argument than before as a justification for this policy. I do not think there’s an intrinsic quality argument to the global single version policy. Bug fix releases are proof that sometimes you do really just need to put out new things to fix a bug.
  - LtWorf 2y ago
    > Why do you think libraries get any releases at all? I mean… you're welcome to write a book and not publish it, just don't expect anyone to read it no? Same thing with libraries.

by rtpg 2y ago

LtWorf 2y ago

If your library changes API all the time, do you think it's a good library? Do you rewrite every API call in your software every time you bump dependencies? Do you think that a library that changes API very often and thus remains insecure because bumping it breaks the program should be running on people's computers?

zozbot234 2y ago
> If your library changes API all the time, do you think it's a good library? If it has a 0.x.y version number? Yes, that's what 0.x means to begin with. In fact Rust/cargo provides a stricter interpretation of semver than the original, which allows you to express guarantees of API stability (by keeping the minor version number fixed) even in 0.x-version projects.
- LtWorf 2y ago
  If it has a 0.x version number it should be good policy to not use it.
rtpg 2y ago
Why do you think libraries get any releases at all? Software A and B depend on C (version V). A has a bug that gets fixed by shipping with C version V+1. B unfortunately has a latent bug that appears when shipping with C (version V+1). You’re now going to have to do a bunch of work, outright not ship stuff, or even introduce bugs because of this policy! Nobody wants buggy libraries, and in this example it’s not the library’s fault (B might just be misusing C, or in fact compensating for a bug). Reading through these threads I’m much more empathetic to the software bill of materials argument than before as a justification for this policy. I do not think there’s an intrinsic quality argument to the global single version policy. Bug fix releases are proof that sometimes you do really just need to put out new things to fix a bug.
- LtWorf 2y ago
  > Why do you think libraries get any releases at all? I mean… you're welcome to write a book and not publish it, just don't expect anyone to read it no? Same thing with libraries.