I have not seen prelease versions utilized pre-1.0.0. It seems fairly pointless since the public API is not finalized yet. They become useful after 1.0.0 is released.
From semver.org:
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
and:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. ...A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. The conventions I have seen pre-1.0.0 include using patches for bug fixes/typos and minor versions for any significant modifications. The conventions are less strict pre-1.0.0 since no public API has been guaranteed yet.
Prelease versions come in handy when you want to share some early features with the community.
For example, at the time of this writing, the latest stable release of npm-check-updates is version 1.5.1
. Some of the new features I have added have introduced backward-incompatible changes, so to conform to semver I will have to release them under 2.0.0
. Yet, I don't want to release 2.0.0
as the latest stable version until it has been more thoroughly tested by the community. Thus, I have published a prerelease version (using npm publish --tag unstable
) versioned at 2.0.0-alpha.1
. Community members can install the prerelease version (with npm install -g npm-check-updates@unstable
) to try out the latest features while a normal npm install -g npm-check-updates
will continue to install the stable 1.5.1
version for most users. When the prerelease has proven itself, I can easily publish it as the new stable at 2.0.0
.