6 ms·

That's not how versions work

by neilsense 6y ago

The_rationalist 6y ago
>= 1.0 in semantic versioning universally means that it should be "stable enough"
- nicoburns 6y ago
  The Rust ecosystem typically has much more conservative version numbers than other ecosystems though, and higher quality standards. There are several very high quality crates with 0.x version numbers.
  - jhasse 6y ago
    They are doing it wrong then.
    - darksaints 6y ago
      One could argue that if you are relying on magic number schemas to decide if a library is stable enough for your usecase, it is you that is doing it wrong.
      - The_rationalist 6y ago
        It's no longer magic number once you follow semver https://semver.org https://semver.org Of course it only offer limited information but this information can tell you whether you should be not confident in it. Pre 1.0 is such a signal.
  - lumost 6y ago
    A fairer statement might be that the rust ecosystem has inconsistent version numbers. I've seen both flawless v.14s and awful v.7s. There are a few ways to figure out the difference like sorting by downloads on crates.io to find packages that are commonly used. There is a curious parallel to the rise of Go which had no versions in their ecosystem as the language was adopted.
- jeffparsons 6y ago
  I think you're missing the point of contention. > [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use. API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production. Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far from a universal principal. I think people often get confused about different meanings of "stable". I've worked with plenty of libraries with stable APIs that are buggy piles of hacks. And I've worked with plenty of libraries with unstable APIs that are rock-solid in production. They're different concerns, but people seem to conflate them a lot. So, to clarify, any statement like "not even 1.0 [...] isn't stable enough for production use", made without qualification, is a non sequitur.
  - kazinator 6y ago
    > plenty of libraries with stable APIs that are buggy piles of hacks. E.g. the API: char *gets(char *s); has not changed in probably forty years. Rock stable!
    - The_rationalist 6y ago
      Not A imply not B, does not imply that A imply B.
      - kazinator 6y ago
        Nobody on the internet but you knows about the contrapositive; but you can fix that!
        The_rationalist 6y ago
        Well I guess I have to expand the symbols for you, here we go: No api stability heuristically imply no production readiness does not imply that api stability imply production readiness. As you snarkily imply, the contrapositive should be common sense and not need to be stated. Yet your brain failed to see that your comment on gets() is exactly such a needless truism.

That's not how versions work

The_rationalist 6y ago

>= 1.0 in semantic versioning universally means that it should be "stable enough"

nicoburns 6y ago
The Rust ecosystem typically has much more conservative version numbers than other ecosystems though, and higher quality standards. There are several very high quality crates with 0.x version numbers.
- jhasse 6y ago
  They are doing it wrong then.
  - darksaints 6y ago
    One could argue that if you are relying on magic number schemas to decide if a library is stable enough for your usecase, it is you that is doing it wrong.
    - The_rationalist 6y ago
      It's no longer magic number once you follow semver https://semver.org https://semver.org Of course it only offer limited information but this information can tell you whether you should be not confident in it. Pre 1.0 is such a signal.
- lumost 6y ago
  A fairer statement might be that the rust ecosystem has inconsistent version numbers. I've seen both flawless v.14s and awful v.7s. There are a few ways to figure out the difference like sorting by downloads on crates.io to find packages that are commonly used. There is a curious parallel to the rise of Go which had no versions in their ecosystem as the language was adopted.
jeffparsons 6y ago
I think you're missing the point of contention. > [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use. API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production. Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far from a universal principal. I think people often get confused about different meanings of "stable". I've worked with plenty of libraries with stable APIs that are buggy piles of hacks. And I've worked with plenty of libraries with unstable APIs that are rock-solid in production. They're different concerns, but people seem to conflate them a lot. So, to clarify, any statement like "not even 1.0 [...] isn't stable enough for production use", made without qualification, is a non sequitur.
- kazinator 6y ago
  > plenty of libraries with stable APIs that are buggy piles of hacks. E.g. the API: char *gets(char *s); has not changed in probably forty years. Rock stable!
  - The_rationalist 6y ago
    Not A imply not B, does not imply that A imply B.
    - kazinator 6y ago
      Nobody on the internet but you knows about the contrapositive; but you can fix that!
      - The_rationalist 6y ago
        Well I guess I have to expand the symbols for you, here we go: No api stability heuristically imply no production readiness does not imply that api stability imply production readiness. As you snarkily imply, the contrapositive should be common sense and not need to be stated. Yet your brain failed to see that your comment on gets() is exactly such a needless truism.