Why a prerelease version always ranks lower

Semver deliberately makes any prerelease tag rank below the same version without one — `1.0.0-alpha` is always considered less than the plain `1.0.0` release, no matter what the prerelease label says. That ordering encodes the real-world meaning directly: a prerelease is explicitly not-yet-ready, a preview of what the final version will become, so it has to sort before the version it's previewing or dependency resolvers would treat an alpha build as satisfying a requirement for the stable release. This is also why bumping from `1.0.0-rc.2` straight to `1.0.0` (dropping the prerelease tag entirely) is itself a valid, meaningful version increase under semver rules, even though the major/minor/patch numbers didn't change.

Why build metadata gets ignored for comparison entirely

The `+build` suffix (as in `1.0.0+20130313144700` or `1.0.0+exp.sha.5114f85`) is explicitly defined by the semver spec to carry no weight in precedence comparisons at all — two versions differing only in build metadata are exactly equal for ordering purposes. This exists to let build metadata carry genuinely useful information (a build timestamp, a commit SHA, a CI run number) for traceability without that information ever affecting how package managers or dependency resolvers order versions — which is precisely why this tool displays it but explicitly labels it "(ignored)" in the comparison table, so the reason two otherwise-different-looking versions still compare equal isn't a mystery.