If the CodeIgniter Community Branch was a fork...

[eluser]Rick Jolly[/eluser]
From an update on the "Official CodeIgniter Community Branch":

Since we are not ready to reveal its name, we were simply trying to avoid calling it something lame like “CodeIgniter Community Edition”, and in haste chose “fork”. We’ve changed the wording in this article to more accurately reflect the intent, using “branch”

Now a branch is something designed to be merged back into the code base. So I don't see any fundamental architectural changes in the future. Nothing that would break backwards compatibility. I suspect the purpose of the Official CodeIgniter Community Branch is to add features and refactor existing code, not improve the architecture.

This strategy makes sense for Ellislab. Their CI-based products continue to work unaltered, and they benefit from new features built and thoroughly tested by the community.

The direction doesn't work for me. There are now other, better framework alternatives that share the same philosophy of simplicity.

So maybe it's pointless to voice my top 5 architectural changes, but here they are:

1. PHP 5 autoloading. So long $this->load->something(). The loader class served PHP 4 well.

2. Common consistent convention for drivers using interfaces that transfers to session, database, cache, etc.

3. Generic solutions:
a. Module system instead of single-purpose solutions like CI 2 packages.
b. Validation library that works on any array, not just $_POST
c. Pagination library that works on any collection, not just database results.

4. No more helper and library distinction, only classes. Helpers become static classes.

5. Depreciate some CI libraries. Focus on CI strengths and support optional bundling and interoperability of some best-of-breed libraries like HTML Purifier, Swift Mailer, Doctrine and others.