I understand why people may think that, but if we try to load too much information into package version numbers (both SemVer and commitment to maintenance) we end up with a suboptimal situation where neither goal is served.
Version numbers simply help dependent packages do upgrades in a scheduled and predictable manner: if the package follows SemVer, by fixing compat to
^1, you can rest assured that nothing should break even if a new version is released, regardless of whether it is a
1.x or a
2.0 release (because the latter won’t be used). Then, when you learn about a
2.0 release with breaking changes, you can review the
CHANGELOG (ideally) and make the required changes in the dependent package when time permits, instead of having things in an inconsistent state.
It is easy to answer when one should release
1.0: when you have packages depending on your package. You can learn this either from the registry, or informally for unregistered packages. Then, if you want to be nice to those other maintainers, it is time to leave
0.x.x land (where basically anything goes in SemVer) and just release a
I think this should be the social norm in the community. Conversely, if a maintainer is unwilling to release a
1.0 despite requests, that should be a strong signal that the package is not reliably maintained. It is important to know this, but it is simply not true for a lot of
0.x packages in the ecosystem, many are consistently maintained and have a lot of dependents.
Incidentally, commitment to maintenance is very difficult to signal reliably. Someone may be committed to maintenance, but just be busy at a given time. Or be interested in maintaining a package for years, then lose interest and abandon it. This is fine, and if the package is useful there should be a culture of adding collaborators, transferring the repository to someone who is interested, or if neither of those happens, forking.