4 ms·

Semver 0.x.y is by spec definition unstable & wild-wild west. https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4

Semver 0.x.y is by spec definition unstable & wild-wild west. https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4 "Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable." There is no code change that makes 0.x.y turn into 1.0.0. This is covered in the FAQ https://semver.org/spec/v2.0.0.html#how-do-i-know-when-to-release-100 https://semver.org/spec/v2.0.0.html#how-do-i-know-when-to-re... It is a case of something vaguely along the lines of "0.3.5 has been running in prod for X time, I am now confident, I will now tag that same code as 1.0.0"

cuddlybacon 6y ago
TIL! Thanks! I always assumed that if you were doing Semver right, then you could end up at 0.124.2 or something. Glad to learn that’s not the case.
- MaxBarraclough 6y ago
  Perhaps I'm missing something obvious, but, why not?
  - jml7c5 6y ago
    Example: semver does not require libfoo 0.4.1 and libfoo 0.4.2 to be compatible in any way. Anything can change between them. It's not until MAJOR >= 1 that the MINOR and PATCH numbers have semantic meaning. Say libfoo 0.4.1's furbinate() function draws a pretty picture. When libfoo 0.4.2 comes out and someone calls furbinate(), they may be surprised to have all their files deleted and their screen covered with filthy Latin poetry, but it is allowed per the semantic versioning spec.
    - fingerlocks 6y ago
      Sure, but still doesn’t explain why one can’t end up at 0.142.2 as noted by GP. Something is missing from this discussion, ninja edit?
      - DougBTX 6y ago
        A version 0.142.2 is perfectly possible with Semver, it just implies that the the developer has had a lot of iterations on the idea, but never got to the point that they consider stable. If the software had a stable API at that point, but they were still using a 0.x.y version number, then they wouldn't be using Semver properly, since 0.x.y versions are for unstable initial development releases. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4
        fingerlocks 6y ago
        Right, I know. But GP implied it was impossible, not just unlikely. Hence the confusion all around.
      - cuddlybacon 6y ago
        I guess my wording was unclear. I thought with semver if you never did a major breaking change then you had to keep the major version 0 forever.
segmondy 6y ago
First code that goes to production is 1.0.0
- rurounijones 6y ago
  Not that cut and tried as it depends what "goes into production" means. As an example: Lets say I have an open-source library that I am developing. It is currently version 0.x.y and someone depends on it (without my knowledge because that is usually how it is). Is that now in Production? Should I be forced to make it 1.0.0 even though I am still making large numbers of breaking changes? That is a simple example off the top of my head. I am watching https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI (Linked from another comment) and he goes into good details about issues with Semver.
  - lathiat 6y ago
    I guess you could say, "intended for production"
    - geofft 6y ago
      Semver 1.0.0 is the first code with an interface stability guarantee, that's it. Whether that correlates with production is up to the engineering team putting it into production. If they budget for dealing with incompatible interface changes when they want/need to update and they don't have automated untested updates of the dependency, it is entirely reasonable to decide to depend on 0.x in production. In turn, it's entirely reasonable for the owner of the dependency to say, this is fine to go into production (it's stable, secure, feature-complete, etc.), I just have a couple of small planned changes to the interface so I don't want to commit to it yet. Another way of thinking about this: semver doesn't say anything about the current version of the code. It says how that code compares to past and future versions.
      - rat9988 6y ago
        Which just makes staying in production in 0.x as useful as not adopting semantic versioning.
JoshTriplett 6y ago
While officially `0.y.z` makes no guarantees, unofficially many people and some tools interpret `0.y.(z+1)` as being compatible with `0.y.z`, treating `y` as the equivalent of a major version and `z` as the equivalent of a minor version. This makes it easier to test pre-release libraries without treating every point release as a breaking change.

cuddlybacon 6y ago

TIL! Thanks! I always assumed that if you were doing Semver right, then you could end up at 0.124.2 or something. Glad to learn that’s not the case.

MaxBarraclough 6y ago
Perhaps I'm missing something obvious, but, why not?
- jml7c5 6y ago
  Example: semver does not require libfoo 0.4.1 and libfoo 0.4.2 to be compatible in any way. Anything can change between them. It's not until MAJOR >= 1 that the MINOR and PATCH numbers have semantic meaning. Say libfoo 0.4.1's furbinate() function draws a pretty picture. When libfoo 0.4.2 comes out and someone calls furbinate(), they may be surprised to have all their files deleted and their screen covered with filthy Latin poetry, but it is allowed per the semantic versioning spec.
  - fingerlocks 6y ago
    Sure, but still doesn’t explain why one can’t end up at 0.142.2 as noted by GP. Something is missing from this discussion, ninja edit?
    - DougBTX 6y ago
      A version 0.142.2 is perfectly possible with Semver, it just implies that the the developer has had a lot of iterations on the idea, but never got to the point that they consider stable. If the software had a stable API at that point, but they were still using a 0.x.y version number, then they wouldn't be using Semver properly, since 0.x.y versions are for unstable initial development releases. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4
      - fingerlocks 6y ago
        Right, I know. But GP implied it was impossible, not just unlikely. Hence the confusion all around.
    - cuddlybacon 6y ago
      I guess my wording was unclear. I thought with semver if you never did a major breaking change then you had to keep the major version 0 forever.

segmondy 6y ago

First code that goes to production is 1.0.0

rurounijones 6y ago
Not that cut and tried as it depends what "goes into production" means. As an example: Lets say I have an open-source library that I am developing. It is currently version 0.x.y and someone depends on it (without my knowledge because that is usually how it is). Is that now in Production? Should I be forced to make it 1.0.0 even though I am still making large numbers of breaking changes? That is a simple example off the top of my head. I am watching https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI (Linked from another comment) and he goes into good details about issues with Semver.
- lathiat 6y ago
  I guess you could say, "intended for production"
  - geofft 6y ago
    Semver 1.0.0 is the first code with an interface stability guarantee, that's it. Whether that correlates with production is up to the engineering team putting it into production. If they budget for dealing with incompatible interface changes when they want/need to update and they don't have automated untested updates of the dependency, it is entirely reasonable to decide to depend on 0.x in production. In turn, it's entirely reasonable for the owner of the dependency to say, this is fine to go into production (it's stable, secure, feature-complete, etc.), I just have a couple of small planned changes to the interface so I don't want to commit to it yet. Another way of thinking about this: semver doesn't say anything about the current version of the code. It says how that code compares to past and future versions.
    - rat9988 6y ago
      Which just makes staying in production in 0.x as useful as not adopting semantic versioning.

JoshTriplett 6y ago

While officially `0.y.z` makes no guarantees, unofficially many people and some tools interpret `0.y.(z+1)` as being compatible with `0.y.z`, treating `y` as the equivalent of a major version and `z` as the equivalent of a minor version. This makes it easier to test pre-release libraries without treating every point release as a breaking change.