The configuration file is part of the public-facing API. As application designers, we have to address the problem of schema evolution. If we change a class definition, how will we change the configuration?

Because configuration files often have useful defaults, they are often very flexible. In principle, the content is entirely optional.

As a piece of software undergoes major version changes – changes that alter the APIs or the database schema – the configuration files too might undergo major changes. The configuration file's version number may have to be included in order to disambiguate legacy configuration parameters from current release parameters.

For minor version changes, the configuration files, such as database, input and output files, and APIs, should remain compatible. Any configuration parameter handling should have appropriate alternatives and defaults to cope with minor version changes.

A configuration file is a first-class input to an application. It's not an afterthought or a workaround. It must be as carefully designed as the other inputs and outputs. When we look at larger application architecture design in Chapter 16, The Logging and Warning Modules, and Chapter 18, Coping with the Command Line, we'll expand on the basics of parsing a configuration file.