Features - branch 2.x results in large info files that exceed the 'info' column limit in the 'system' table Original thread on DO (will keep it up to date)

Hello. I am currently developing a mid-to-large project. As i've done before, but using the 1.x branch, I use Features to track all structural and functional components of my site in order to be able to transfer them from my local installation, to the staging server, to the production server etc, while also having svn capabilities and tracking.

The current project consists of 45 Content Types with an average of 15 fields each. There are also ~15 vocabularies, ~10 fieldgroups, and a couple of tons of views.

The problem occurs when trying to track all this stuff with Features. It produces a large (initially, just alpha versions of the Content Types) .info file ( > 100K) which results in the following error:

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'info' at row 1: UPDATE {system} SET info=:db_update_placeholder_0 WHERE
// yada yada yada serialized array of the .info file

Which is totally natural seeing that the collumn is declared as a BLOB.

My question, is how should one go about to manage such a problem?
1) perform a ALTER TABLE system CHANGE info info LONGBLOB /* or MEDIUMBLOB */ NULL DEFAULT NULL? (Ouch)
2) Use branch 1.x instead which is less verbose in the .info file declarations?
3) Break down the project and track it in multiple features? (I'd avoid this cause it will make reverting those features a hellish job since one would depend on the other and vice versa)
4) ...?

I'd appreciate any input on the matter
The way I see it, you have options:

Features

Break your Features down into smaller Features.  Yes, this might make the dependencies a little more effort to manage, but a Feature containing that many content types, as well as other config does seem a little extreme.

If you do break them up, and are worried about dependencies, create a controller module to deal with them.  Every time you add/break down a Feature, add it as a dependency to this controller module, then make your new Feature depend on the controller module.

This means that all other dependencies will be inherited by the Feature, but you've only had to declare it in one place. When you then disable any part of your Feature, everything will get disabled - which is the same behaviour as having one monolithic Feature.

As an added bonus, if you perform updates to your Features that require hook_install or hook_update_N, they can go in the controller module.

Configuration Management

If the idea of breaking down your Features really sends shivers down your spine, then check out Configuration Management, which can do what you want (track EVERYTHING), and if pretty easily extensible if you are happy writing your own code. This is also the route Drupal 8 is taking/has taken with configuration management, so with this method you'll be future-proofing your own knowledge.

My personal preference is Features, but if you are looking for something that wouldn't involve you breaking down a huge Feature into smaller ones, then Configuration Management is a solid option.