Maven compares versions by splitting them into tokens and ranking known qualifiers in a fixed order: alpha, beta, milestone, rc (same as cr), snapshot, then the plain release (final, ga and release are equal to it), then sp. Trailing zeros are trimmed, so 1.0.0 equals 1. Comparison is also case insensitive.
The documented rules
The Maven POM reference describes the algorithm in detail. Each version string is split at dots, hyphens, underscores, and at transitions between digits and letters. Empty tokens become 0. Then trailing null values (0, an empty string, final, ga) are trimmed, and the shorter sequence is padded with nulls so the two can be compared.
The special qualifiers come first in a set order: alpha, beta, milestone, rc equal to cr, snapshot, then the unqualified release, then sp. The letters a, b and m can stand for alpha, beta and milestone when followed directly by a number. Other alphabetic tokens come before numeric tokens and compare case insensitively.
Worked examples from the rules
| Version | Becomes after trimming |
|---|---|
| 1.0.0 | 1 |
| 1.ga | 1 |
| 1.final | 1 |
| 1.0 | 1 |
| 1.0.0-foo.0.0 | 1-foo |
So a library published as 1.0 and one published as 1.0.0 are the same version to Maven. A scanner that compares the strings literally would call them different.
Where it differs from SemVer
The same page says the Maven algorithm follows SemVer 1.0.0 precedence in most ordinary cases but is not compatible with SemVer 2.0.0. It does not special case the plus sign or build identifiers. It is also case insensitive where SemVer is case sensitive: 3.2-ALPHA1 compares greater than 3.2-alpha1 under SemVer, and equal under Maven.
Two things follow. First, the sp qualifier sorts above the plain release, so 1.0-sp1 is newer than 1.0. A naive string comparison could place it before. Second, snapshot sorts above rc but below the release. So 2.0-SNAPSHOT is older than 2.0 and newer than 2.0-rc1.
Why this matters for security checks
Affected ranges in advisories for Java libraries use introduced and fixed versions. To decide whether your dependency is inside, a tool must order your version against those bounds using the right rules. If it uses plain numeric or string comparison, qualified versions can land on the wrong side.
Practical checks:
- If your dependency has a qualifier, work out its position using the order above.
- Prefer final releases in production. A snapshot is a moving target, since it is not a fixed artifact, and it is hard to tie to an advisory.
- When a scan flags or clears a qualified version, compare against the fixed version by hand once to see that the tool agrees.
- Record the exact version string in your SBOM.
Caution
Do not assume that rc or milestone builds contain a later fix just because the number looks high. Ordering tells you which is newer, not whether a particular fix is present. Use the advisory's fixed version, or the project's release notes, to confirm.
Safeguard's SBOM and dependency scanning keeps the versions your builds resolve to, and the free scan lets you see them for a repository of your own.
Quick check
Is 1.0-sp1 newer or older than 1.0 in Maven?
Newer. The documented order places sp after the plain release.
Are 1.0 and 1.0.0 the same in Maven?
Yes. Trailing zeros are trimmed, so both reduce to 1.
Sources
Last reviewed: 19 October 2026.
