Maybe this is the wrong place to ask, but will dbal/orm be switching cache implementations?

Yes. We are in the process of preparing DBAL, ORM, and all other internal users of doctrine/cache to no longer depend on the cache implementations. We will retain backward compatibility to the interfaces, but those methods will be deprecated and will not be part of the next major release.

Is the plan to make the uses of doctrine/cache be also compatible with a psr implementation? Or will we have to use something like the new PSR6 adapter?

the PSR-6 adapter is part of the migration layer: when a library depends on the doctrine/cache interface for its caching layer, you can use the PSR-6 adapter to wrap your PSR-6 caching library, to provide it to the place needing doctrine/common.
The idea is that it would be the only non-deprecated implementation in 2.0.

In the longer term, the idea is that libraries that depend on doctrine/cache today should migrate to consume PSR-6 directly (that's the work that is in progress for DBAL, ORM and other Doctrine projects).

Thanks! That makes it clear to me

After working on removing doctrine/cache from various doctrine libraries, here is an updated timeline.

We will introduce two new classes in doctrine/cache 1.11:

• Doctrine\Common\Cache\Psr6\DoctrineProvider exposes a PSR-6 cache as doctrine/cache. This is required as some Doctrine libraries (e.g. the metadata factories from doctrine/persistence) leak their caches, which requires this compatibility code. This class is not designed for end users, but rather as a stop-gap solution for library authors to build a backward compatibility layer. This class was marked as @internal as people shouldn't transform PSR-6 caches to doctrine/cache unless absolutely required.
• Doctrine\Common\Cache\Psr6\CacheAdapter works the other way around and exposes any doctrine/cache as PSR-6 cache. This class is needed for forward compatibility layers to allow users to inject legacy doctrine/cache implementations but build on PSR-6 functionality. This class is also not designed for end users, but can be used as a stop-gap solution if need be.

doctrine/cache 1.11 will not mark existing cache implementations as deprecated. This is done to allow the ecosystem to start migrating away from doctrine/cache before we trigger multiple deprecation notices. These deprecations will be done in 1.12, which will be released once the various doctrine libraries no longer directly rely on doctrine/cache implementations but support PSR-6.

doctrine/cache 2.0 will drop all cache implementations, but will retain the two compatibility classes in the Doctrine\Common\Cache\Psr6 namespace.

For any software that allows configuring doctrine/cache, we recommend to bump the doctrine/cache dependency to ^1.11 || ^2.0 once 1.11 has been released. From then on, you can start deprecating any code points that use doctrine/cache and build compatibility layers using the classes mentioned above.

If your software uses doctrine/cache implementations (e.g. ArrayCache), you should remove their usages before allowing doctrine/cache 2.0. To avoid unnecessary dependency complications for users, no application should require doctrine/cache 2.0 - version 1.11 should be the lowest constraint until all code points have been removed, at which point you may safely remove the dependency to doctrine/cache.

the components we rely on jumped to 2.x automatically because doctrine/orm allows it in its composer.json, so things get broken with just a composer update, without us being aware of anything or having made a choice..

This happened in one of our projects as well, but that was because we used code from this dependency without having it as an explicit dependency ourselves. If you rely on code of a package it should be an explicit dependency.

You could use a tool like https://github.com/maglnet/ComposerRequireChecker to find where you are using code that you aren't explicitly requiring.

edit: it would help much if you provided examples of alternative components, or maybe how to migrate to a "good" one

The alternative is to use PSR-6 (or PSR-16 if you prefer), for which packagist has several maintained packages implementing it. That's precisely why doctrine/cache is being sunset, as Doctrine decided to migrate to using PSR-6 instead of maintaining its own cache library.

@GregOriol consider @BackEndTea 's approach to life: there is a good to fair chance that, like him, you or the components you are using were missing an explicit dependency : doctrine/cache is referenced in https://github.com/dflydev/dflydev-doctrine-orm-service-provider/blob/0c7aaa4315b25d899fc125003e9ed843b216fc9a/src/Dflydev/Provider/DoctrineOrm/DoctrineOrmServiceProvider.php#L14-L22 , but never referenced in https://github.com/dflydev/dflydev-doctrine-orm-service-provider/blob/master/composer.json

There was no need to antagonize us like that, and I think an apology would be in order.

You know @GregOriol, if you had only been less of a prick I would've loved to help you out. Do you seriously think I've never been in your situation? Do you think that in more than a decade of full-time work as an engineer I've never faced a situation like that?

So when you see an issue like this, why would you even think that I just got up one morning and decided to "break things that worked well"? Instead, if you had checked the timeline, you'd have realised that this issue was created in December 2020, and that we released 1.11 announcing the deprecation on April 22, 2021. Besides that, as you can see from the plan laid out in the OP, there's a lot of thinking that went into this. In fact, the first work for this was done at SymfonyCon 2019 in Amsterdam.

Countless people have dedicated their personal time for this to ensure a smooth transition. You only need to check if you're instantiating any cache implementations. As for alternatives, we decided to only suggest any PSR-6 implementation, since that's what your framework of choice will provide. I'd consider it unfair to suggest a particular implementation, since you may not necessarily have a choice: you may already be using a PSR-6 adapter of choice, your framework may provide you with a cache component that integrates with PSR-6, or you may have created your own thing. Either way, that's why we have standards: so that people can choose the best tool for the job.

Speaking of the best tool, let's look at doctrine/cache 1.x. It is used by millions and millions of projects. If we look at Packagist install statistics, you can see that the package is getting close to ~200k installs per day. Yet, over the past few years, only a few people (less than 20) have contributed to the package in any way. Adapters started becoming useless, the code was not being updated, nobody investigated bugs. In the wider scheme of things at Doctrine, this project was becoming a nuisance. It was built in 2008 because at the time, there was no cache library. It was very specific to what Doctrine ORM needed, but since it was always there when you used Doctrine, people started using it for everything. Now, we no longer have the time or energy to maintain this. The code has aged, and just like not every wine will age well, not every code will. There are obscure cache implementations in there that probably nobody uses, and we're probably missing a number of features. However, they are not relevant for Doctrine: we don't want to figure out how to efficiently cache stuff; we have the need to cache something, and if other tools can do it better, we use those.

So after a lot of discussions that took a serious toll on my mental health, I made a push to drop doctrine/cache from our own tools. People can still use it: "doctrine/cache": "^1.11" is all it takes. We won't fix bugs, but then that's the beauty of open source: you can fix them yourself. Remember, Open Source maintainers don't work for you, they work with you. In order to not break code that uses doctrine/cache as a generic library, we provide an adapter to accept PSR-6 caches so that you technically don't even have to change anything: add new public API to inject a PSR-6 cache, wrap it in our adapter, and you're good to go. Then you can drop doctrine/cache at your own pace, and the code necessary for that is minimal and well-tested since we shamelessly copied it from Symfony with their permission.

And all of that process, over 1.5 years, countless hours of thinking, countless attempts to not break every single composer install on this planet for millions of people by introducing hard BC breaks, we arrive here, in this issue. I get a notification out of nowhere (as you can see, there was little response to this ticket in general) and I have to read the comment. So here's what I'll do. I'll assume that you were just minding your own business at your job, run composer update, run your tests and are greeted by failures. You do some investigation and find this issue. And now you think that some moronic idiot you've never did everything they could to cause this, and you let them know. I honestly don't care how much work you have to do to get out of your mess. I don't care if changing to a different cache library is a million dollar effort for your company or for you. If that's what you're concerned about, I've got news for me: pay me, and I can work for you. Don't pay me, and you'll have to take my "sod off" for what it is: me showing you the door.

As a reminder to everyone reading this issue: OPEN SOURCE MAINTAINERS DON'T WORK FOR YOU! They are people with jobs that share a passion. If you want to contribute to this community in a meaningful way. If you can't do that, you're free to play in your corner and leave us alone.

I'm locking this discussion, because I have no desire to condone this kind of behaviour by allowing people like that to keep tooting into the same horn repeatedly. Nothing to see here, move along.