Question: Which version(s) in 4.* series actually support PHP 8.1?

[asgrim]

ramsey/uuid:4.0.0 declares it is compatible with PHP ^7.2 || ^8 meaning it can be installed on PHP 8.1. Clearly, it is not compatible with PHP 8.1, and follow up issues (such as #378) indicate this. Due to using ^8 in that version, history cannot be changed, so sadly, it will always and forever declare it is compatible with PHP 8.1 😭

So, trying to be proactive, I look at the changelog to try and find where PHP 8.1 support was introduced:

uuid/CHANGELOG.md

Lines 9 to 98 in cd372a7

	## 4.2.3 - 2021-09-25
	### Fixed
	* Switch back to `^8.0` in the PHP version requirement.
	## 4.2.2 - 2021-09-24
	### Fixed
	* Indicate support for PHP 8.1, using `~8.1.0` to prevent installations on 8.2
	until the library is ready.
	## 4.2.1 - 2021-08-10
	### Fixed
	* Fix *soft* BC break with `Uuid::fromString()` signature. The change from
	`string` to `non-empty-string` on the parameter annotation introduced a
	BC break for those using static analysis tools. This release reverts this
	change and provides an assertion to guard against empty strings.
	See [ramsey/uuid#383](https://github.com/ramsey/uuid/pull/383).
	## 4.2.0 - 2021-08-06
	### Added
	* Add `Ramsey\Uuid\Exception\UuidExceptionInterface` for all ramsey/uuid
	exceptions to implement. See [ramsey/uuid#340](https://github.com/ramsey/uuid/pull/340).
	### Fixed
	* Fix serialization of UUIDs.
	See [ramsey/uuid#361](https://github.com/ramsey/uuid/pull/361).
	## 4.1.3 - 2021-09-25
	### Fixed
	* Switch back to `^8.0` in the PHP version requirement.
	## 4.1.2 - 2021-09-24
	### Fixed
	* Lock 4.1.x to `~8.0.0` to indicate it does not support PHP 8.1.
	## 4.1.1 - 2020-08-18
	### Fixed
	* Allow use of brick/math version 0.9
	## 4.1.0 - 2020-07-28
	### Changed
	* Improve performance of `Uuid::fromString()`, `Uuid::fromBytes()`,
	`UuidInterface#toString()`, and `UuidInterface#getBytes()`. See PR
	[#324](https://github.com/ramsey/uuid/pull/324) for more information.
	## 4.0.3 - 2021-09-25
	### Fixed
	* Switch back to `^8.0` in the PHP version requirement.
	## 4.0.2 - 2021-09-24
	### Fixed
	* Lock 4.0.x to `~8.0.0` to indicate it does not support PHP 8.1.
	## 4.0.1 - 2020-03-29
	### Fixed
	* Fix collection deserialization errors due to upstream `allowed_classes` being
	set to `false`. For details, see [ramsey/uuid#303](https://github.com/ramsey/uuid/issues/303)
	and [ramsey/collection#47](https://github.com/ramsey/collection/issues/47).

The version constraint seems to have been changed multiple times.

My use case is: I'm maintaining a library that consumes ramsey/uuid: ^3.0|^4.0. In my CI pipeline, I've added PHP 8.1, and in the composer install --prefer-lowest, because of the above constraint that was "too wide" at the time, I will always have ramsey/uuid:4.0.0 installed. Since changing history tags is messy/terrible idea, the only practical solution for this is to adjust my own constraint to something like ramsey/uuid: ^3.0|^4.?.?, but due to the repeated changes to the version constraint in the lifetime of 4.* series, I am left confused and unsure which version is the lowest release of ramsey/uuid in the 4.* series that actually DOES support PHP 8.1.

So my question is: which release of ramsey/uuid in the 4.* series actually supports PHP 8.1 currently please?

[ramsey]

Version 4.2.2 is the first version that truly supports PHP 8.1.

When I did that release, I thought it would be good to use ~8.1.0 and to also tag the 4.0.x and 4.1.x series with updates to limit them with ~8.0.0. I was later convinced that this had been a bad idea, so I changed everything back to ^8.0.

I’m very sorry for the confusion this caused. I’m not sure the best way to handle and communicate compatibility with future PHP versions, since PHP itself doesn’t follow semver.

[ramsey]

There was a thread somewhere (maybe on Twitter?) where I think I discussed these changes with @Ocramius, but I can’t seem to find it now.

[asgrim]

Yes indeed; FWIW, my approach tends to be something like 7.1.*|7.2.*|7.3.*|7.4.*|8.0.*|8.1.* for example, to be moderately specific :) Thank you for getting back to me Ben, I'll pin to ^3.0|^4.2.2 and that should solve things 👍