DB design to avoid versioning inconsistencies between the application layer and the database layer
The approach you're think of is called Entity-Attribute=Value (EAV). If you Google around for it you'll find very quickly that it is almost universally reviled.  In short, it's generally a bad idea because it doesn't let your relational database management system do what it was designed to do.

As an alternative, you should think about schema changes as something that you need to keep backward compatible.  This often means that new columns will be nullable or have defaults set.  Depending on what you want to do with your application, though, sometimes a database change is simply a breaking change and you can't release the database change without releasing the corresponding code change.

I've seen some people keep a short code table in their database that contains version information in it (e.g. minimum and maximum supported code versions). The idea with this is that when your application starts it does a quick lookup in the code table and if the database version isn't compatible with the code the code exits gracefully.