Personally, I think the 0 major version is a bad idea. I hear the desire to not want to have to make guarantees about stability in the early stages of development and you don't want people depending on it. But hiding that behind "v0.x" doesn't change the fact that you are releasing versions and people are depending on it.

If you didn't want people to depend on your package (hence the word "dependency") then why release it? If your public interface changes, bump that major version number. What are you afraid of? People taking your project seriously?

▲

jaapz 2 days ago | parent | next [-]

0.x is not that you don't want people depending on it, you just don't want them to come and complain when you quickly introduce some breaking changes. The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change. It is up to the user to decide whether they are OK with this.

1.x communicates (to me at least) you are pretty happy with the current state of the package and don't see any considerable breaking changes in the future. When 2.x comes around, this is often after 1.x has been in use for a long time and people have raised some pain points that can only be addressed by breaking the API.

▲

moron4hire 2 days ago | parent | next [-]

If you are at the point that other people can use your software, then you should use v1. If you are not ready for v1, then you shouldn't be releasing to other people.

Because this comment, "The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change." That describes every project. Every project is always in development. Every project is stable until it isn't. And when it isn't, you bump the major number.

▲

the__alchemist 2 days ago | parent [-]

I think we can come up with a reason why bumping the version number each breaking change isn't an elegant solution either: You would end up with version numbers in the hundreds or thousands.

▲

zokier 2 days ago | parent [-]

Browser version numbers are in the hundreds and it doesn't seem to be a problem.

	▲	the__alchemist 2 days ago \| parent [-]
		Indeed! I think both 0-based versioning, and this (maybe?) downside I bring up addresses the tension between wanting to limit the damage caused by breaking changes with retaining the ability to make them.

▲

OtomotO 2 days ago | parent | prev [-]

But people will complain, so ex falso quodlibet

▲

mort96 2 days ago | parent | prev | next [-]

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.

▲

moron4hire 2 days ago | parent [-]

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.

▲

mort96 2 days ago | parent [-]

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.

▲

steveklabnik 2 days ago | parent [-]

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.

▲

mort96 2 days ago | parent [-]

Oh hey I recently saw a comment which discussed this exact issue: https://news.ycombinator.com/item?id=47752915

▲

steveklabnik 2 days ago | parent [-]

99% of the time this situation is okay, because Cargo allows you to have both 0.1 and 0.2 in the same project as dependencies. It's just packages that call out to external dependencies, like libc, where it enforces the single version rule.

▲

mort96 2 days ago | parent [-]

You can have both 0.1 and 0.2 in the same project, but you really don't want to.

	▲	steveklabnik 2 days ago \| parent [-]
		Most of the time, it works so well people don't even notice. The only time you run into a problem is if you try and use values with a type from 0.1 with a function that takes a 0.2 as an argument, or whatever. Then you get a type error.

▲

maxloh 2 days ago | parent | prev [-]

[dead]