Kai Sassnowski

I've run into a slight issue while adding the return types. The `mixed` type has only been added in PHP 8.0, so it's not possible to add it as a...

In that case I would tend towards using the `#[ReturnTypeWillChange]` attribute instead of `mixed` and keeping everything on one branch. The branches would be literally identical in _features_, they would...

That still leaves the question about whether the 2.0 branch should require PHP 8 and up or not. Otherwise we'd still have to fall back to using `#[ReturnTypeWillChange]`.

Ok, then I will prepare two PRs, one for each new major version 👍

Opened a PR for version 1.0 (#70). I'm honestly not sure if creating a separate branch for PHP 8 and up is worth it. The 1.0 branch would already work...

I don't believe that dropping support for a PHP version is even a breaking change. Composer will ensure that the new version simply won't get installed is the PHP version...

Some relevant links: - https://github.com/semver/semver/blob/d460299638d3d2af6fcf809285dc6a469e15742a/semver.md#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api - https://sebastiandedeyne.com/composer-semver-and-underlying-dependency-changes/ In short, if my application requires PHP 7.3, it will simply not install a newer version of this package that requires PHP 7.4...

Sounds good. Thanks!

The tag doesn't seem to be available on Packagist yet. This looks related to an old issue of mine (#65) where the package doesn't seem to auto update on Packagist....

No worries 🤘