These are the features and issues that the council deems necessary to resolve or make decisions on, before the rest of the CodeIgniter 4 planning/roadmap/implementation can proceed. Each of the issues will have a huge impact on the architecture/implementation of other features/issues. This thread conveys our thoughts and decisions.
We welcome your comments, but please stay on topic! This thread is about the essential features of CI4. If you try to hijack the thread, or post non-relevant items that should be or that are dealt with elsewhere, your posts will be deleted without notice. We may post additional comments in fgeature/issue specific threads.
PHP version: PHP 5.5, or the lowest officially supported PHP version at the time of planned release. Impact: plan on 5.5 language features , but not 5.6+
Community input: 23% for 5.4; 13% for 5.5; 50% for 5.6
Using more PHP "standards": yes. We plan to take advantage of new language features, such as namespaces, traits, generators, etc.
Community input: overwhelmingly in favor.
Composer: We are in favour of more composer integration, but not to the point where CI4 *has* to be installed via composer.
Community input: 50% in favor, but many looking for backwards compatibility
Module support: with namespaces, and composer support/integration, we expect most of the "module" issues to fade away.
Community input: overwhelmingly in favor.
Hooks/events: as a replacement/enhancement for the existing kinda hooks mechanism ... makes sense, details to be worked out during implementation.
Community input: 87% in favor of this idea.
GIT repo organization: We favor a separate repo for CI4, but a single one, incorporating the framework files and the user guide. It will be sufficiently different from CI3 that this makes sense. It would be cool if CI4 could be deployed from the repo download *or* from composer, per developer preferences.
Community input: no poll setup. Comments: all over the map.
"Borrowing code" from other frameworks: maybe, big maybe, if such other components can be integrated without pulling in loads of dependencies & expectations. Not clear that this would be super helpful or not.
Community input: no poll setup. Comments: all over the map.
Micro framework: No. CI has always been "full-stack". We expect that developers may wish to make their own "distribution", to this end.
Community input: no poll setup. Comments: all over the map.
Magic routing toggle: we agree - conventional "CI magic" or fully declared routing.
Community input: 80% in favor.
Bundling other packages: big no. No ORM, scaffolding, auth, etc, etc. That is NOT what CI is about. Making it easy to integrate other such packages: +1
Dependency injection: cool idea. Has the possibility of making "plugins" and "modules" easier, as well as eliminating the "CI super object".
Community input: mixed.
Backwards compatibility: makes sense as a way to ease the pain of migration to CI4? Would be awkward in most cases!
Community input: BC garnered only 9% vs ease of use, modern & speed as "vision" considerations.
Driver support: we are in favor of "drivers" as a mechanism to handle developer preferences, eg for "standard" third party stuff. We already have drivers in some places, of course we'll have it in some form where it makes sense.
James Parry
Project Lead
