Windows has always had its own versioning conventions: historically it was a one-digit major and a two-digit minor, so windows 2.1 was 2.10 in full (its predecessor was 2.03, and it was followed by 2.11), and NT 3.5 was followed by NT 3.51.

This scheme was moved away from with Windows 10, which switched to a year/month versioning scheme (so the first W10 update was version 1511, as it was released in November 2015), then to the current "halves" system.

There was also a minor upgrade to Windows 3.1 called Windows 3.11, which further reinforces your point.

Yeah, in my mind, 3.11 > 3.1 as well, because I consider 3.1 to be 3.10 in this case. If they stick to only 3.0, 3.1, etc. then 3.2 would have been the next logical step, so I assume 3.11 is a minor version increment.

What software do you use that follows this convention? I can't think of any (as a trivial example, Linux 3.10 and 3.11 were released several years after 3.1, and after Linux 3.9).

Every package manager I've ever used works the same way too. For projects that use SemVer, this is even explicitly standardised.

Seems like we are all over the place. If you ignore the rest of my message (me considering it 3.10, which is not always the case, in retrospect), would you say "3.11 > 3.1" is false?

Because according to "vercmp", it is true: https://news.ycombinator.com/item?id=44634420.

  $ ./vercmp-gnu 3.11 3.1
  3.11 > 3.1
  $ ./vercmp-arch 3.11 3.1
  3.11 > 3.1

GNU version just uses "strverscmp()" ("sort -V" probably uses it). See the man page, it includes an example that shows you this output.

Which means what I said is correct, just not for the reasons I have provided, because I incorrectly said that I perceive "3.1" to be identical to "3.10", because they are not identical (although they could be in some cases).

  $ ./vercmp-arch 3.1 3.10
  3.1 < 3.10
  $ ./vercmp-gnu 3.1 3.10
  3.1 < 3.10

This statement of mine is also incorrect: "I assume 3.11 is a minor version increment.", but it depends really. 3.11 should be greater than 3.2, not the other way.

So, most projects and package managers do it the way I correctly said (if we ignore the rest of my message), not the way Perl does it.

By the way:

  $ ./vercmp-gnu 1.05 1.10
  1.05 < 1.10
  $ ./vercmp-gnu 1.05 1.1
  1.05 < 1.1

  $ ./vercmp-arch 1.05 1.10
  1.05 < 1.10
  $ ./vercmp-arch 1.05 1.1
  1.05 > 1.1

Arch Linux's is expected, as "05 < 10", but "strverscmp()" interprets "1.05" as "1.5". That said, neither of the two are Perl-style.

Yes, 3.11 > 3.10 > 3.9 > 3.8 > ... > 3.2 > 3.1 > 3.0 > 2.999999 in basically every versioning system I've seen.

The algorithm is very simple -- you treat each component as a separate number and the newest version is the one which has the earliest left-most component with a numerically larger value. The rules are bit more complicated for suffixes (3.1-beta, 4.5~rc7, 14.2+devel) but stuff like SemVer has formal specs describing a similar algorithm for version comparisons (though SemVer has some subtle differences to the scheme used by most distro package mangers -- at least this is definitely the case for RPM).

I can see the argument for 3.05 == 3.5 > 3.1 (05 is a number that is equivalent to 5 and is larger than 1), and think that makes more sense than 3.05 < 3.1 (I guess that would mean 3.05 == 3.0.5 < 3.1? That's more than a bit fruity...) but I would personally prefer the packaging system reject such versions. Otherwise you need to make up rules for other nonsense like 3.-1 < 3.0 (??!). Of course, I suspect RPM would accept them all.

FWIW, I work at a Linux distribution company (SUSE) and have had to deal with these corners cases a lot.

I'd agree that 3.11 > 3.1 whether we're considering it a version, a float, or a string.

I agree.