@nicolas-grekas thank you for the patch, but just to make it clear it targets the main branch (that is, the future v2.0 which is still in development and will take a few months to reach a stable release) while symfony/symfony#37993, as far as I understand, should most likely be based upon v1.1... is it intentional?

I'd be happy to target a lower branch. It should be 1.2 then, isn't it (unless you'd consider this as a bugfix?)
Please advise :)

Actually I missed the line in symfony/symfony#37993 with the check class_exists(UNLINK::class) so yeah it will still work just fine with v1.1 simply falling back to DEL, but then again please note that sooner or later, before the actual release of v2.0, we will rename command classes in the main branch to avoid clashes with current and future keywords (it happened with OBJECT and we had to rename the class associated to this command to Predis\Command\Redis\OBJECT_), but there's nothing set in stone about how and when we will rename these classes.

I'd be happy to target a lower branch. It should be 1.2 then, isn't it (unless you'd consider this as a bugfix?)
Please advise :)

To be honest I would have liked to avoid introducing a v1.2 and stick with patch releases for v1.1, but aside from UNLINK we really miss too many commands from Redis 4, 5 and 6 so this would mean stretching the role of patch releases a bit too much.

@predis/team what should we do, branch off a new v1.2 branch and leave v1.1 as is or just stick with v1.1?

I guess v1.1patch releases makes sense.

I don't consider this a bug fix, so I'm not sure I think it should go into v1.1. A v1.2 would make more sense to me.

Fine to me for 1.2 of course. How can I help make this happen?

Feel free to re-submit to the main branch for the 2.0 release.