Naturally, the users should treat those libraries as beta versions and only use them in production at their own risk.
> you can’t properly declare a new release to be a feature or bugfix
0.5.0 vs 0.4.1?
In practice, 0.5 can be assumed to be breaking but then how do you specify non breaking new features? 0.4.1? Moving to 1.0.0 makes things a lot clearer. For breaking, just go to 2.0.0 etc
You don’t. As soon as you feel the API is stable enough, move to 1.0.0. 0.x is for the “yeah the API doesn’t feel right just yet but it might be useful for early adopters” stage.
I know there’s the tendency for mature projects to live in 0.x for a long while, yeah – definitely try to avoid that. But 0.x is a useful first step for libraries, especially if the API is non-trivial.
There is a case to be made to always start at 1.0, especially libraries with public API’s. The reason is that if you use semantic versioning then below 1.0 you can’t properly declare a new release to be a feature or bugfix release (for example, 0.4 to 0.5. Is this bugfix or feature?). Above 1.0.0 this is easy (for example 1.1.0 vs 1.0.1).