Additional packages for specific drivers/storages


(Alexander Makarov) #1

I’ve recently created i18n package that is PHP-generic message translation/formatting package. While planning it dependencies were analyzed and some decisions were made:

  1. Suggested packagist dependencies aren’t particularly good. They’re hiding a problem in package dependencies.
  2. A generic package, that framework will likely depend on, should be as stable as possible. That means containing only interfaces or, in a less ideal but practical world, interfaces and part of the implementation that is unlikely to change.
  3. Specific backends/drivers should be in their own packages as:

I am going to follow the same approach for RBAC, mutex and other packages where there are multiple ways of storing data.


(muitosefala) #2

Excelent Aproach! Thank you Alexander and team for your efforts.


(Alexander Makarov) #3

We’re now applying it to everything we’re moving to separate packages. Hard to do initial splitting but should be much easier to maintain.