(Assuming we don't reach "GA" yet)

I was updating a dependency in a project using go modules, and noticed that the runc dependency was downgraded from v1.0.0-rc10 to v1.0.0-rc6 (a version specified in another dependency). Scratching my head why v1.0.0-rc9 "stuck", but v1.0.0-rc10 was "ignored" by go modules, I had a 🤦 moment, and recalled that the runc pre-release tags are missing a dot separator.

This worked until -rc9, but broke when -rc10 was released;

Due to the missing separator in the release candidates:

v1.0.0-rc10

• v (prefix)
• 1 (major)
• 0 (minor)
• 0 (patch)
• - (it's a pre-release)
• rc10 (pre-release suffix)

So for v1.0.0-rc6, the pre-release suffix (which is just anything you name it), is rc6, and for v1.0.0-rc10, the suffix is rc10.

These suffices are compared alphabetically, not numerically, only releases with the same pre-release suffix are comparable.

So, when sorted alphabetically;

v1.0.0-rc1
v1.0.0-rc10
v1.0.0-rc2
v1.0.0-rc3
v1.0.0-rc4
v1.0.0-rc5
v1.0.0-rc6
v1.0.0-rc7
v1.0.0-rc8
v1.0.0-rc9

If a dot separator was used, the situation would be:

v1.0.0-rc.10

• v (prefix)
• 1 (major)
• 0 (minor)
• 0 (patch)
• - (it's a pre-release)
• rc (pre-release suffix)
• 10 (pre-release version for rc suffix)

In which case, the order (oldest -> newest) would be:

v1.0.0-rc.1
v1.0.0-rc.2
v1.0.0-rc.3
v1.0.0-rc.4
v1.0.0-rc.5
v1.0.0-rc.6
v1.0.0-rc.7
v1.0.0-rc.8
v1.0.0-rc.9
v1.0.0-rc.10

You can see the behavior here;

• without separator https://semvercompare.azurewebsites.net/?version=1.0.0-rc1&version=1.0.0-rc2&version=1.0.0-rc6&version=1.0.0-rc10&version=1.0.0-rc20
• with separator https://semvercompare.azurewebsites.net/?version=1.0.0-rc.1&version=1.0.0-rc.2&version=1.0.0-rc.6&version=1.0.0-rc.10&version=1.0.0-rc.20

I propose to skip v1.0.0, and tag the next -rc as v1.0.1-rc.0 or v1.0.1-rc.1, in which case version comparison works correct again

v1.0.0-rc1
v1.0.0-rc10
v1.0.0-rc2
v1.0.0-rc20
v1.0.1-rc.1
v1.0.1-rc.2
v1.0.1-rc.10
v1.0.1-rc.20