Additional packages for specific drivers/storages

[samdark (Alexander Makarov)]

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:

• https://github.com/yiisoft/i18n-message-php
• https://github.com/yiisoft/i18n-message-gettext
• https://github.com/yiisoft/i18n-formatter-intl
  Such structure makes it possible to depend on i18n but not to require intl extension or db package except in the application itself that is by definition the most unstable package. Another profit is that these drivers could be maintained/released separately.

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

[muitosefala]

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

[samdark (Alexander Makarov)]

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.