5 ms·

If stability is important to you, just don't use software tagged 0.x.y. It's not like it's going to be more stable if the authors are forced to mark it 1.0.0.

If stability is important to you, just don't use software tagged 0.x.y. It's not like it's going to be more stable if the authors are forced to mark it 1.0.0. At least authors are honest that their goal at the moment of release is not stability but their freedom to break it every release if they see a reason for it.

mumblemumble 6y ago
It's not really about whether the software is actually more stable, it's the signaling the project gives by choosing to hold their version numbers in semver's semantic no-man's-land where the version numbers aren't expected to give a clear indication of the severity of the change. In particular, what the signal says is, "We aren't yet ready to think about or support the needs of someone who's trying to use this in production." Which, if the project is also then pitching the software as production-ready, is a terrible mixed message. Maintainers really should pick one story and stick with it.
- kerkeslager 6y ago
  > In particular, what the signal says is, "We aren't yet ready to think about or support the needs of someone who's trying to use this in production." > Which, if the project is also then pitching the software as production-ready, is a terrible mixed message. Maintainers really should pick one story and stick with it. Yes, that's true, but you've got to realize that these messages are often coming from different teams. Versions are more likely to come from engineers, whereas pitches are more likely to come from sales. As an engineer, version numbers are one of the few tools I have for telling the truth when sales is lying. Engineers generally don't want to promise stability that isn't fully-formed, because if a valuable enough client starts using it, then we end up supporting some horrible half-baked interface until they decide to upgrade. In that context, when you see version numbers disagreeing with marketing, don't point the finger at semantic versioning as "refusing to tag a 1.0.0 release". They're the ones telling you the truth. Point the finger at marketing. In a larger sense, the sooner you start viewing all marketing as untrustworthy and basing your decisions on evidence instead, the happier you'll be. Version numbers are a small signal. Actual trial periods and getting to use the software should be the real deciding factor. And don't make the mistake of turning a trial period into a commitment without actually evaluating whether the software does what you want it to.
  - mumblemumble 6y ago
    It's kind of hard to rest things like a huge chunk of the world's computing infrastructure basing itself on OpenSSL long before the product put out its 1.0 release on the usual "don't trust marketing" finger-tutting. Did OpenSSL even have a marketing team back in the early 2000s?
    - kerkeslager 6y ago
      Sure, hype isn't necessarily based on marketing. That's why there's the word "often" in my previous post. I think in the case of OpenSSL, there was a huge need for what OpenSSL was doing which justified a lot of people taking a calculated risk to use it. I'll concede in that case that the risk may have actually even been justified. That same logic doesn't apply to blahblah.io's "revolutionary" 0.x.y packages on npm or pip, or the bleeding-edge SaaS of the week.
mfer 6y ago
To a consumer a 1.0.0 may be more stable. At a 1.0.0 you expect the authors to not change the API for what ever the API is for the thing. Your interactions with the software have an expected level of stability and authors don't need to take into account prior to that. Stable means no changing or firmly established. Once you tag a 1.0.0 you say that some things will no longer change. Hence, an element of stability.
- ryan_lane 6y ago
  No, it means that anything within 1.0 won't change, but that 2.0.0 and above will include breaking changes from 1.0.0. That's the whole point. Semver versions don't imply general stability of the service, just stability of the interface within the major versions. If you're depending on the software in your dependencies, you can mark >1.0.0,<2.0.0 and if people are correctly doing semver, your software won't break. When you need to move to another major version, you'll need to ensure your usage hasn't broken with the change.

mumblemumble 6y ago

It's not really about whether the software is actually more stable, it's the signaling the project gives by choosing to hold their version numbers in semver's semantic no-man's-land where the version numbers aren't expected to give a clear indication of the severity of the change. In particular, what the signal says is, "We aren't yet ready to think about or support the needs of someone who's trying to use this in production." Which, if the project is also then pitching the software as production-ready, is a terrible mixed message. Maintainers really should pick one story and stick with it.

kerkeslager 6y ago
> In particular, what the signal says is, "We aren't yet ready to think about or support the needs of someone who's trying to use this in production." > Which, if the project is also then pitching the software as production-ready, is a terrible mixed message. Maintainers really should pick one story and stick with it. Yes, that's true, but you've got to realize that these messages are often coming from different teams. Versions are more likely to come from engineers, whereas pitches are more likely to come from sales. As an engineer, version numbers are one of the few tools I have for telling the truth when sales is lying. Engineers generally don't want to promise stability that isn't fully-formed, because if a valuable enough client starts using it, then we end up supporting some horrible half-baked interface until they decide to upgrade. In that context, when you see version numbers disagreeing with marketing, don't point the finger at semantic versioning as "refusing to tag a 1.0.0 release". They're the ones telling you the truth. Point the finger at marketing. In a larger sense, the sooner you start viewing all marketing as untrustworthy and basing your decisions on evidence instead, the happier you'll be. Version numbers are a small signal. Actual trial periods and getting to use the software should be the real deciding factor. And don't make the mistake of turning a trial period into a commitment without actually evaluating whether the software does what you want it to.
- mumblemumble 6y ago
  It's kind of hard to rest things like a huge chunk of the world's computing infrastructure basing itself on OpenSSL long before the product put out its 1.0 release on the usual "don't trust marketing" finger-tutting. Did OpenSSL even have a marketing team back in the early 2000s?
  - kerkeslager 6y ago
    Sure, hype isn't necessarily based on marketing. That's why there's the word "often" in my previous post. I think in the case of OpenSSL, there was a huge need for what OpenSSL was doing which justified a lot of people taking a calculated risk to use it. I'll concede in that case that the risk may have actually even been justified. That same logic doesn't apply to blahblah.io's "revolutionary" 0.x.y packages on npm or pip, or the bleeding-edge SaaS of the week.

mfer 6y ago

To a consumer a 1.0.0 may be more stable. At a 1.0.0 you expect the authors to not change the API for what ever the API is for the thing. Your interactions with the software have an expected level of stability and authors don't need to take into account prior to that. Stable means no changing or firmly established. Once you tag a 1.0.0 you say that some things will no longer change. Hence, an element of stability.

ryan_lane 6y ago
No, it means that anything within 1.0 won't change, but that 2.0.0 and above will include breaking changes from 1.0.0. That's the whole point. Semver versions don't imply general stability of the service, just stability of the interface within the major versions. If you're depending on the software in your dependencies, you can mark >1.0.0,<2.0.0 and if people are correctly doing semver, your software won't break. When you need to move to another major version, you'll need to ensure your usage hasn't broken with the change.