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

[James Titcumb]

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?

[Ben 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.

[Ben 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.

[James Titcumb]

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 👍