Put out a new release

[shish]

to-do:

• get unit tests working in all currently-supported versions of PHP
• get automatic updates working
• check to see if any outstanding PRs are still useful, merge them if so
• check to see if any bug reports are still relevant, add them as bullet points below
  • ?
• check to see if any feature requests are super-duper important, implement them (if they aren't super-duper important I'd rather put out a stable release before adding new features)
  • ?
• pick a version number (IIRC "dropping support for old versions of PHP" is defined as "needs a major version number bump", but I haven't checked that)
• what else?

[staabm]

I think we should put out a beta since its our first release

[staabm]

After we got a beta out we should check the phpstan-plugin whether it needs some love to work with the beta

[oojacoboo]

PHP 8.4 deprecations are an issue for anyone that doesn't ignore them. A 2.5.1 release that at least fixes this would be nice.

[maks-rafalko]

Commenting for visibility of a problem and to subscribe to a topic:

absence of a release produces a lot of deprecations for the projects that use this lib. For example, in Infection we had to stick to dev-master to avoid deprecations, but even this leads to issues, like infection/infection#2015 (comment)

so if you could do a quick release with the fixes for 8.4, that would be awesome.

[shish]

The deprecation warnings are a superficial and obvious issue, but the version incompatibilities run deeper than that. Speaking only for myself, not all the maintainers - I don't want to put out a new release which fixes a superficial issue, only to give people the impression that the project is healthy, and have them run into worse problems.

If you really hate the warnings, don't want to silence them, and are willing to deal with worse issues - you can switch from thecodingmachine/safe to shish/safe temporarily (it is marked as a replacement package, so you only need to switch in the top-level composer.json and it will propagate through your dependencies, and you should be able to switch back just as easily)

[jhdxr]

#421 may be a starting point as it's target php8.1, which is still under security fix for one year.

Personally I suggest to bump the version to 3.0 and targeting php 8.3 (8.2 is going to end active support in around 2 weeks), which gives us more flexibility to introduce new/bc break features/changes if necessary.

For people staying with 8.1/8.2, I think current version should be fine. We can still have bugfix on this branch (2.x) until the end of 8.2.