Member-only story
Demystifying Semver Prereleases
A guide to unleashing the full potential of collaborative, iterative upgrades in library and API development
What is a Prerelease?
Part of the semver spec
In semantic versioning, version numbers are typically composed of three parts: major, minor, and patch. The major version number indicates significant changes likely to introduce breaking changes or require significant user adaptation. Minor version numbers indicate smaller changes that may add new functionality but are unlikely to require significant changes to existing code. Patch version numbers indicate bug fixes and minor updates that do not change the public API. In essence, the further right you go, the less significant the change.
This comes to mind when most people think of semantic versioning: major, minor, and patch numbers separated by dots. But Semver also defines a much lesser-used component called “pre-releases.”
Prereleases in semantic versioning are identified by appending a hyphen and a string of characters to the end of the version number. This last component is fairly flexible, but the most common convention is to use common values, such as “alpha,” “beta,” or “rc” (release candidate), followed by a dot-separated prerelease value. This would look like 5.0.0-beta.3 or 2.7.0-rc.1.
That first example is a “major version prerelease” because it only has a non-zero major version component. (The minor and patch components are zero.) The second example would be considered a “minor version prerelease.”
Like “negative minor versions”
Major version prereleases represent a “step forward” regarding progress and development. Similar to a final major version release, consumers of the prerelease will get the latest API with all of its new functionality. Because the “step forward” is big enough to incur breaking changes, it definitely falls after the current major version.
“Prereleases represent a “step forward” regarding progress and development and a “step backward” in terms of stability and completeness”.
