Ordering Explicit Versions

[Nixinova]

In this spec, pre-release identifiers (like 1.6.2.0-Alpha1) are treated the same to release identifiers (like 3.5.0.1-LTS_2021-07). However, this should not be the case; when ordering versions, pre-releases should be placed before the full release and EOS & LTS should probably be placed after.

This spec doesn't mention how versions should be compared, something like 0.16.1.4 < 1.0.0.0-Alpha1 < 1.0.0.0-Beta2 < 1.0.0.0-RC1.

I'd recommend following the SemVer method of using a plus sign to append metadata about the build, which I would consider EOS & LTS to be a part of (for example, 1.0.6.2+LTS_2020-12), and then also follow the SemVer method of ordering versions by disregarding the contents of the metadata and then comparing in numerical order for the dotted versions and ASCII order for the pre-release identifiers. i.e., disruptive -> incompatible -> compatible -> fix -> identifiers, which release versions being ordered after pre-releases. This change would split §Optional Identifiers into a new section about build metadata, which could also be expanded on to support information other than EOS & LTS like build IDs etc.

[Exadra37]

Hi @Nixinova. I have edited your issue format in order to make it more readable.

Thanks for you suggestions, and I will give them a though.

At a first glance:

• I can say that I like your suggestion of using the + to separate the metadata.
• I agree that we may have a section that explicitly specifies how versions must be compared, because now we only address it partially with the examples given in the documentation.