Comment by mort96
1 day ago
Versioning is communication. I find it useful to communicate, through using version 0.x, "this is not a production ready library and it may change at any time, I provide no stability guarantees". Why might I release it in that state? Because it might still be useful to people, and people who find it useful may become contributors.
Any project may change at any time. That's why they bump from v1 to v2. But by not using the full precision of the version number, you're not able to communicate as clearly about releases. A minor release may not be 100% compatible with the previous version, but people still expect some degree of similarity such that migrating is not a difficult task. But going from v0.n to v0.(n+1) uses that field to communicate "hell, anything could happen, YOLO."
Nobody cares that Chrome's major version is 147.
By releasing a library with version 1.0, I communicate: "I consider this project to be in a state where it is reasonable to depend on it".
By releasing a library with version 0.x, I communicate: "I consider this project to be under initial development and would advice people not to depend on in unless you want to participate in its initial development".
I don't understand why people find this difficult or controversial.
There is additional subtlety here.
For example, sometimes projects that have a 0.y version get depended on a lot, and so moving to 1.0.0 can be super painful. This is the case with the libc crate in Rust, which the 0.1.0 -> 0.2.0 transition was super painful for the ecosystem. Even though it should be a 1.0.0 crate, it is not, because the pain of causing an ecosystem split isn't considered to be worth the version number change.
4 replies →