4 ms·

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 curre

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.
bigbizisverywyz 6y ago
>Should I be forced to make it 1.0.0 even though I am still making large numbers of breaking changes? Yes, but then your next version could be 1.1.x and might even include the odd interface/API changes without feeling at all guilty.
- rurounijones 6y ago
  I disagree, someone else deciding to use my 0.x.y version library does not obligate me to suddenly make it 1.0.0. I think geofft sums it up best elsewhere in this thread where it is about interface stability guarantees being the deciding quality.

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.

bigbizisverywyz 6y ago

>Should I be forced to make it 1.0.0 even though I am still making large numbers of breaking changes? Yes, but then your next version could be 1.1.x and might even include the odd interface/API changes without feeling at all guilty.

rurounijones 6y ago
I disagree, someone else deciding to use my 0.x.y version library does not obligate me to suddenly make it 1.0.0. I think geofft sums it up best elsewhere in this thread where it is about interface stability guarantees being the deciding quality.