A SemVer-compatible intuitive comparator for free-form versioning strings as seen in the wild, designed to sort versions like people do.
  • Go 20.5%
  • C# 17.3%
  • D 13.5%
  • Java 13.1%
  • Rust 11.1%
  • Other 24.5%
Find a file
2025-06-02 00:04:46 -04:00
.github python: New port (#22) 2023-10-09 17:20:36 -07:00
crystal crystal: Fix handling of leading zeroes 2023-07-23 12:01:07 -07:00
csharp fix(csharp,java,js): removeLeadingZeroes '0' != '00' (#21) 2023-07-23 11:45:32 -07:00
d d: Fix tests on windows, style fixes (#14) 2023-01-17 11:52:30 -08:00
go rust, go, java, js: Implement #3 (#10) 2023-01-16 16:18:19 -08:00
java java: Publish completed, update instructions to use Central 2025-06-02 00:04:46 -04:00
js fix(csharp,java,js): removeLeadingZeroes '0' != '00' (#21) 2023-07-23 11:45:32 -07:00
python python: New port (#22) 2023-10-09 17:20:36 -07:00
rust rust: Rewrite & address #12 (#13) 2023-01-17 08:55:47 -08:00
test test: Add test vector for normal leading zeroes 2023-07-23 12:01:16 -07:00
.gitattributes Gradleify and rewrite Java implementation to be more idiomatic 2022-11-06 01:59:28 -07:00
LICENSE Initial commit 2022-11-06 01:23:16 -07:00
logo.svg meta: Add logo 2022-11-08 01:10:18 -08:00
poetry.lock python: New port (#22) 2023-10-09 17:20:36 -07:00
pyproject.toml python: New port (#22) 2023-10-09 17:20:36 -07:00
README.md meta: Add logo 2022-11-08 01:10:18 -08:00
shard.yml crystal: New implementation (#9) 2023-01-17 09:02:15 -08:00
SPEC.md spec: Increment version for removeLeadingZeroes change 2023-07-23 12:05:22 -07:00

FlexVer

FlexVer is a SemVer-compatible intuitive comparator for free-form versioning strings as seen in the wild. It's designed to sort versions like people do, rather than attempting to force conformance to a rigid and limited standard. This repo collects meta information and discussion on FlexVer, as well as implementations of it in various languages. Notably, it houses a specification.

It works by splitting a string into "numeric" and "non-numeric" parts, and then sorting those lexically, with a few special cases for SemVer compatibility. This mode of operation is similar to how sort -V behaves in GNU coreutils. As such, when used solely for simple comparisons and not group-aware things (such as ~ matches), it is also a stand-in for a SemVer parser (with one exception — read on)

The initial Java implementation contains a test harness used to initially verify the logic, seen below:

image

Cyan is numeric, pink is non-numeric, red is SemVer pre-releases, and gray is ignored SemVer-style appendices. As the potential problem space of version number comparisons is infinite, I cannot devise a good way to truly verify this is a completely sound implementation; so, I simply cherry-picked some random examples of versions that I felt would trip up a version comparator, which both do and do not follow SemVer. As such, there are no unit tests; I feel a system like this only benefits from regression tests, after basic sanity tests done during development.

It is a non-goal for comparisons between versions of entirely different structures to "make sense" — but nonetheless, it does try its best and will normalize structural differences and fall back to lexical comparison when all else fails. Fundamentally, FlexVer does not impose any form of restrictions — it will always do its best to compare two strings and never throw an exception. If you do pass two completely different versions to it, well....

image

...the results won't necessarily make sense. Garbage in, garbage out.

There is one known case where FlexVer and SemVer disagree. It is related to pre-releases, as they are an exception to the intuitive version flow. There is a special case that makes the most common forms of them work, such as -pre1, -rc2, -beta.2, etc. However, this works by looking for a non-numeric component that starts with - and is longer than one character. As such, if you have a pre-release starting with a numeral, then FlexVer's normal parsing kicks in, which sorts 1.0.0 and 1.0.0-2 in the opposite order that SemVer would. However, I have never seen fully numeric pre-releases like this in the wild; a hyphenated numeric like that is generally meant to represent another "group" of versions — in which case, FlexVer does indeed sort it as expected.