What actually changes when a project releases version 1.0.0?

Under semantic versioning the criterion is specific and it is about compatibility promises, not quality.

Before 1.0.0, the specification explicitly says anything may change at any time. There is no obligation to keep the interface stable and no way to signal a breaking change, because the major number is already zero. Consumers are on notice that upgrading may break them.

At 1.0.0 you commit to the versioning contract: breaking changes require a major bump, new features get a minor bump, fixes get a patch. That is all it means.

So the honest answer to "what has been achieved" is: the maintainer has decided the public interface is worth committing to. Not that the software is complete, not that it is bug-free, not that it is fast. Purely that they are prepared to stop changing the shape of it without warning.

Which is why 0.x libraries are used in production constantly — quality and stability of interface are different axes, and only the second one is being claimed.

The reason "0.x means not production ready" persists despite being wrong is that the two things correlate in practice, for reasons that have nothing to do with the specification.

A maintainer who has not yet committed to an interface is often still exploring the design, which often means the library is young, which often means fewer users have found the bugs. The inference is unreliable but it is not baseless.

What I would actually look at when evaluating a dependency, in order:

• Release history. Regular releases over a couple of years says more than any version number.
• How breaking changes have been handled in the past. Look at the changelog for the last major bump and see whether there was a migration path.
• Issue response. Are bugs acknowledged, and roughly how quickly.
• Who else depends on it, and whether anyone significant does.

All four are observable in ten minutes and all four are better signals than the leading digit.

There is a cultural wrinkle worth knowing: some very widely used projects stay at 0.x deliberately and indefinitely.

The reasoning is usually that the maintainers do not want to make the compatibility promise, either because the domain is still moving or because they would rather keep the freedom to fix design mistakes. Some of those projects are extremely stable in practice despite the number.

And in the other direction, plenty of projects release 1.0.0 as a marketing event tied to a launch. The number is set by a person, and people have motives.

So treat it as a declaration of intent by the maintainer rather than as a measurement of anything.

For anyone maintaining something and wondering when to do it: the practical trigger is when breaking your users starts costing more than keeping your freedom.

If three people use your library, breaking changes are a message in a chat. At three hundred, every breaking change is a day of support and a long tail of people stuck on an old version. Somewhere in between, committing to a contract becomes the cheaper option, and that is the moment for 1.0.0 regardless of how finished it feels.