Given the two version strings `1.5.0-beta.2` and `1.5.0+build.20260104`, what does the `-beta.2` suffix versus the `+build.20260104` suffix each mean under the SemVer spec, and which one (if either) affects how two versions compare for precedence?

## Two suffixes, one grammar SemVer's full grammar is `MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]`, and the two optional suffixes exist to solve two entirely different problems, which is why they use different separator characters and behave differently under comparison. ## The hyphen — pre-release identifiers The hyphen-prefixed pre-release identifier (e.g., `-alpha`, `-alpha.1`, `-beta.11`) exists to let a maintainer publish a version heading toward a specific target release without claiming that target is final. `2.0.0-alpha.1` announces 'this is on its way to becoming 2.0.0, but isn't stable yet.' Mechanically, the spec defines pre-release identifiers as always having lower precedence than the associated normal version: `1.0.0-alpha` < `1.0.0-alpha.1` < `1.0.0-alpha.beta` < `1.0.0-beta` < `1.0.0-beta.2` < `1.0.0-beta.11` < `1.0.0-rc.1` < `1.0.0` Comparison walks the dot-separated identifiers left to right: - each identifier is compared **numerically** if both sides are purely numeric, and **lexically** (ASCII sort order) otherwise; - with **numeric identifiers always sorting lower** than alphanumeric ones when compared against each other; - and **a version with more pre-release fields outranking** an otherwise-identical prefix with fewer fields. This ordering is what lets a resolver correctly place a release candidate below its eventual stable release without a human hardcoding a special case. ## The plus — build metadata The plus-prefixed build metadata (e.g., `+001`, `+20260104.sha.5114f85`) exists for a different purpose: attaching an immutable, informational identifier to a specific build artifact — a CI build number, a commit SHA, a timestamp — without that identifier meaning anything about compatibility or readiness. The spec is explicit that build metadata **MUST be ignored** when determining version precedence, so `1.0.0+build1` and `1.0.0+build2` are considered equal versions for resolution purposes even though the strings differ. This is why registries like npm historically don't even support publishing multiple packages that differ only in build metadata — it's metadata about provenance, not a versioning axis. ## Two different audiences The reason these two mechanisms exist separately traces back to two different consumers of the version string. - **Pre-release identifiers** are for humans and package managers deciding whether to install this at all by default — virtually every package manager (npm, Cargo, Go modules) excludes pre-release versions from default range resolution; `^2.0.0` will not silently resolve to `2.1.0-beta.1` unless the consumer explicitly opts in, because a pre-release is an explicit signal of instability that automated tooling should not silently adopt. - **Build metadata**, by contrast, is for humans and CI/CD systems doing forensics — which exact commit produced the artifact running in production — without needing to affect what a dependency resolver does. ## The trade-off The main trade-off is **expressiveness versus resolver complexity**: allowing arbitrary dot-separated pre-release identifiers gives maintainers a rich vocabulary (alpha/beta/rc, numbered iterations, date-stamped nightlies) but pushes real comparison-logic complexity into every SemVer-parsing library, and inconsistent conventions across projects (some use `-rc.1`, others `-rc1`) can produce surprising sort orders. ## Failure modes Failure modes show up primarily as either accidental adoption or accidental rejection of pre-releases. - **Accidental adoption:** a resolver misconfigured to allow pre-release ranges can pull an unstable `-beta` build into a production build unintentionally. - **Build metadata and precedence:** conversely, a common mistake is assuming build metadata affects precedence — a CI pipeline that tags two builds `1.2.3+ci.101` and `1.2.3+ci.102` and expects a dependency range to distinguish or prefer the later one will find that most tooling treats them as the exact same version, so if both got published, resolution behavior is effectively arbitrary, which is why build metadata is a poor substitute for an actual version bump when reproducible, distinguishable resolution is needed. ## Where it shows up A concrete real-world instance: Kubernetes and many CNCF projects publish long strings of `-rc.N` and `-beta.N` pre-releases ahead of a stable release specifically so users who want early access can pin to them explicitly while resolvers default to skipping them, and container image tags frequently append build metadata like digests pinned alongside a SemVer tag for traceability without that metadata participating in any range logic at all.