Support larger MAJOR version numbers

[onethumb]

• We prefer to use CalVer + SemVer (YYYYMMDD as MAJOR) for versioning.
• Other software, like npm, supports this: https://github.com/npm/node-semver/blob/bdda212f4f6126a1b8821dc0731a17fdc2fc533f/classes/semver.js#L48
• Composer breaks with an invalid version string because it's limited to 5 digits:

root@0c6964ad69d6:/var/project# COMPOSER_ROOT_VERSION=20230131.0.0 composer install

  [UnexpectedValueException]
  Invalid version string "20230131.0.0"

While we're at it, we may as well be future-proof (support & test YYYYMMDDhhmm and PHP_INT_MAX).

[Seldaek]

Ok I took another look at this and fixed it to avoid causing any changes to existing parsed formats, because the problem is version_compare is quite picky (e.g. version_compare('202301310000.0.0.0', '202301310000.0.0', '=') is false because of one added .0 at the end, this is the reason we normalize versions)

The tests without any changes to VersionParser fail the following new formats which were not supported before:

UnexpectedValueException: Invalid version string "20230131.0.0"
UnexpectedValueException: Invalid version string "202301310000.0.0"
UnexpectedValueException: Invalid version string "20100102.1.0"
UnexpectedValueException: Invalid version string "20100102.0.3"
UnexpectedValueException: Invalid version string "2010-01-02-10-20-30.0.3"

And with the patch those 5 are now supported but no existing one changes.

So really all this does is allow date formats with <date>.x.y where as we previously only allowed <date> or <date>.x.

I think I can live with this patch now, as it appears harmless, but I'd still like confirmation from @naderman before merging.

[naderman]

I think this does cause a BC break in version comparisons though?

Previously the version string "20230131" would have been normalized to "2023.01.31.0" but now it gets normalized to "20230131.0.0.0" which means that

• before: "20230131" < "2023-02-01" normalized to "2023.01.31.0" < "2023.02.01.0"
• after: "20230131" > "2023-02-01" normalized to "20230131.0.0.0" > "2023.02.01.0"

I don't know if this kind of comparison ever mattered to anyone in practice though as it would really just come up if you ever switched from major version date formats without separators to ones with separators or vice versa.

[naderman]

Nevermind the above, the old code never inserted separators, just replaced existing separators with dots, so that issue doesn't exist. Looks all good to me then!