Support larger MAJOR version numbers#149
Conversation
- 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: root@0c6964ad69d6:/var/project# COMPOSER_ROOT_VERSION=20230131.0.0 composer install [UnexpectedValueException] Invalid version string "20230131.0.0"
src/VersionParser.php
Outdated
|
|
||
| // match classical versioning | ||
| if (preg_match('{^v?(\d{1,5})(\.\d++)?(\.\d++)?(\.\d++)?' . self::$modifierRegex . '$}i', $version, $matches)) { | ||
| if (preg_match('{^v?(\d{1,' . PHP_INT_MAX . '})(\.\d++)?(\.\d++)?(\.\d++)?' . self::$modifierRegex . '$}i', $version, $matches)) { |
There was a problem hiding this comment.
PHP_INT_MAX on 64bit (9223372036854775807) is only 19 characters long so if anything it should look something like this IMO as that's the char length and not the max number:
| if (preg_match('{^v?(\d{1,' . PHP_INT_MAX . '})(\.\d++)?(\.\d++)?(\.\d++)?' . self::$modifierRegex . '$}i', $version, $matches)) { | |
| if (preg_match('{^v?(\d{1,20})(\.\d++)?(\.\d++)?(\.\d++)?' . self::$modifierRegex . '$}i', $version, $matches)) { |
The problem though is this is only meant to parse x.y.z versions <100000, and then below we have the code for datetime versions but which do already support many formats as you can see in the tests. I'm not entirely sure yet why your format isn't supported but I don't think this fix is appropriate as I believe it changes the behavior for existing formats.
There was a problem hiding this comment.
Good point about value vs char length. Open to whatever works best... just would like to use YYYYMMDD.y.z :)
There was a problem hiding this comment.
If other versions can be of any size - can they really, does composer support it fully? - then this should be simply \d++ to be consistent.
|
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. The tests without any changes to VersionParser fail the following new formats which were not supported before: And with the patch those 5 are now supported but no existing one changes. So really all this does is allow date formats with I think I can live with this patch now, as it appears harmless, but I'd still like confirmation from @naderman before merging. |
|
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
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. |
|
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! |
YYYYMMDDasMAJOR) for versioning.npm, supports this: https://github.com/npm/node-semver/blob/bdda212f4f6126a1b8821dc0731a17fdc2fc533f/classes/semver.js#L485digits:While we're at it, we may as well be future-proof (support & test
YYYYMMDDhhmmandPHP_INT_MAX).