SemVer 2.0.0 compliant version for nightly builds

[mikaeldui]

SemVer 2.0.0 (used for NuGet packages):

$9: A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. $10: Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.

Moving the build date to build metadata would prevent packages from being pushed to repos and downloaded by NuGet clients. Thus it must to be on the left side of the plus sign in order to give the package precedence, if there are no other version increments. It also makes sense to use the date as version for a nightly build.

Current version example: 3.0.0-nightly-2021-12-30-6d67c5d9bd (❌ non-compliant) New version example: 3.0.0-nightly.2021-12-30+6d67c5d9bd (✅ compliant)

This was initially discussed in #70.

[mikaeldui]

From https://semver.org:

Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows:

1. Identifiers consisting of only digits are compared numerically.
2. Identifiers with letters or hyphens are compared lexically in ASCII sort order.
3. Numeric identifiers always have lower precedence than non-numeric identifiers.
4. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal.

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

This means that 3.0.0-nightly.2021-12-30+6d67c5d9bd < 3.0.0-nightly-2022-01-11-6d67c5d9bd 🙀 and that 3.0.0 would have to be bumped.

The current syntax does work. 💭

SemVer Compare:

[MingweiSamuel]

I'll have to get 3.0.0 stable finally released I suppose. Lcu is the main subpackage that isn't really stable