How does maven sort version numbers?

Since version 3.0, Maven uses a consistent system to compare version numbers for both individual versions and version ranges. The system now makes a lot of sense, once you’ve understood a few gotchas.

All comparisons are now done by ComparableVersion, which says:

  • mixing of ‘-‘ (dash) and ‘.‘ (dot) separators,
  • transition between characters and digits also constitutes a separator: 1.0alpha1 => [1, 0, alpha, 1]
  • unlimited number of version components,
  • version components in the text can be digits or strings,
  • strings are checked for well-known qualifiers and the qualifier ordering is used for version ordering. Well-known qualifiers (case insensitive) are:
    • alpha or a
    • beta or b
    • milestone or m
    • rc or cr
    • snapshot
    • (the empty string) or ga or final
    • sp
  • Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive),
  • a dash usually precedes a qualifier, and is always less important than something preceded with a dot.

This means that versions come out in the following order, which I think makes perfect sense, apart from 1.0-SNAPSHOT right in the middle:

  • 1.0-beta1-SNAPSHOT
  • 1.0-beta1
  • 1.0-beta2-SNAPSHOT
  • 1.0-rc1-SNAPSHOT
  • 1.0-rc1
  • 1.0-SNAPSHOT
  • 1.0
  • 1.0-sp
  • 1.0-whatever
  • 1.0.1

The main gotcha I found in all this is that snapshot comes after beta or rc, so you can’t have a development version of 1.0-SNAPSHOT, then release 1.0-beta1 or 1.0-rc1 and have Maven understand that those are later.

Also note that 1.0-beta-1 is exactly the same as 1.0beta1, and 1.0 is exactly the same as 1 or 1.0.0.

Version ranges now work (nearly) the way you’d expect, too. For example, [1.0-alpha-SNAPSHOT,1.0] will find 1.0-beta1-SNAPSHOT, 1.0-beta1, 1.0-rc1-SNAPSHOT, 1.0-rc1, 1.0-SNAPSHOT or 1.0, preferring later items over earlier ones. This is fully supported by mvn versions:resolve, M2Eclipse and so on.

Leave a Comment