PSR-06 gives a caching interface for interoperability. Whilst doing this will be a BC break for your code and major version bump, it will give greater flexibility for your dependent libraries, Formidable in particular. Most dev shops will already have caching sorted and not want to use yet another one. By implementing PSR-06, you can flexibility in allowing users to utilise a different caching system that uses a different storage mechanism.
Now, there is some controversy as to whether PSR-06 is fit for purpose (see here and follow the links.) So you may not want to. There is evidence that it is gaining ground though, (see here.) Instead, you may want to consider supplying a new interface definition and use that as the type hint, with your caching mechanism implementing it. It would have to be a bit more generic than your current one, as that is very bound to using files. Consider replacing setCacheDirectory($cacheDirectory) with setCacheOptions(array $options) for instance
PSR-06 gives a caching interface for interoperability. Whilst doing this will be a BC break for your code and major version bump, it will give greater flexibility for your dependent libraries, Formidable in particular. Most dev shops will already have caching sorted and not want to use yet another one. By implementing PSR-06, you can flexibility in allowing users to utilise a different caching system that uses a different storage mechanism.
Now, there is some controversy as to whether PSR-06 is fit for purpose (see here and follow the links.) So you may not want to. There is evidence that it is gaining ground though, (see here.) Instead, you may want to consider supplying a new interface definition and use that as the type hint, with your caching mechanism implementing it. It would have to be a bit more generic than your current one, as that is very bound to using files. Consider replacing setCacheDirectory($cacheDirectory) with setCacheOptions(array $options) for instance