I have been playing with the following idea: commonly when different release series (1.0.x, 1.1.x, development code) of a product are maintained in parallel one uses different branches within a version control system to develop them. In theory though one could use feature macros (written from a C/C++ point of view, but the idea should be portable) to enable or disable particular features based on the version which is being built. In C/C++ this would most likely mean enclosing code for new features in #ifdef FEATURE_X and either enabling or disabling them on the build command line or having a master header file containing code like
#if version > 101
# define FEATURE_X
# define FEATURE_Y
#endif
Back-porting features, if one needs to do so, could be done by rearranging this file.
The idea behind this is that normally one will want to back-port fixes and improvements which are not part of significant new features to older versions unless one has a specific reason not to. However, these back-ports are often done in a rather haphazard way, resulting in unintended subtle differences between versions or forgotten fixes in certain versions. The feature macro approach reverses things, by making back-porting the default and explicitly marking code sections which are not for back-porting. While it would not be a silver bullet by any means, it might improve the level of stability which one would achieve with a given amount of testing. I would also expect it to improve code structure by forcing cleaner separation of different features.
So the question: does anyone know of real-world data about this or similar approaches?
12
It is more common to use source control branching in order to control what features are available within a particular version of the software.
That said, applications that offer tiered functionality within the same version level will sometimes use the technique you describe. Usually, you’ll see two main uses of the conditional definitions. The fist uses of the #defines declares the per-tier functionality for that tier’s build. The second usage is throughout the code where the per-tier functionality actually needs to be enabled.
In other cases, backwards compatibility on an otherwise breaking change can be maintained through the use of #defines and the application version. This gets a bit more tricky and yields less easily maintained code, but is a convenient way of keeping all the relevant code together in a single branch. The developer has to remember to revert the version number when making a special, backwards compatible build, but it does allow the older code to remain inline with the rest of the source code.
1