This patch is based on https://github.com/ramsey/uuid/pull/405
As discussed in https://github.com/ramsey/uuid/pull/405#discussion_r832095457, the `ramsey/collection`
dependency can be phased out.
Doing so via direct removal is not feasible without a clear BC break, so this change only deprecates:
* `Ramsey\Uuid\Builder\BuilderCollection`
* `Ramsey\Uuid\Provider\Node\NodeProviderCollection`
These classes will then be removed in `5.0.0`, along with the `ramsey/collection` dependency.
In practice, when @dependabot sends a patch, this workflow will be triggered once the `build`
workflow is completed successfully, and applicable patches will be automatically merged.
While trying out latest `main`, it became evident that CI is not really stable, in its current
state, because dependencies like `phpunit/phpunit`, `vimeo/psalm`, `phpstan/phpstan` and `squizlab/php_codesniffer`
keep shifting within the boundaries of `composer.json`.
In order to freeze them in place, `composer.lock` is introduced, so that they can be upgraded
individually, therefore preventing headaches when installing the project locally, for either
verifying a bug, or contributing to it.
This change is a bit of a shift from the previous approach, but should allow for better stability,
and better dependency upgrade/checking, so that @dependabot patches breaking CI can be identified
more easily.
`substr()` only fails when one of the inputs is not a `string`, but that no longer
holds true as per `php:^8.0`, since the input must be a `string` upfront.
TL;DR: polyfills are to be installed by downstream consumers, and not provided by libraries
In order to support PHP 7.2, 7.3 and 7.4, the `symfony/polyfill-php80` library
was dragged in. Symfony now has a long track record of bad stability ranges
(see https://github.com/symfony/polyfill-php80/blob/f4386d7f6f66346254ed4e6bfa4354d2d16b83f8/composer.json#L22-L24),
so it is best to get rid of it, and instead declare API compatibility with a stable API
version (in this case PHP 8.0).
In addition to that, to avoid introducing an explicit `ext-ctype` requirement, `symfony/polyfill-ctype`
was dragged in too, perhaps in an attempt to retain more popularity.
Same as above: symfony has a bad track record of SemVer compliance, so it should
not be introduced until strictly necessary. `ext-ctype` is generally available to most target
installation systems, and downstream consumers are still free to pull out their foot-gun by
doing a `composer require symfony/polyfill-ctype` on their own.
This mean that systems having `ext-ctype` installed will get an installation as expected: otherwise,
any system that requires `ramsey/uuid` automatically becomes a system capable of providing `ext-ctype`
API, which is just not true (before this change).
Ben Ramsey
Marco Pivetta
dependabot[bot]
hubipe
Lewis Cowles
Sergey Romanenko
Sergiy Petrov
Graham Campbell