1

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
  • meta.programmers.stackexchange.com/questions/6483/…
    – gnat
    Commented Jan 26, 2015 at 10:28
  • 1
    The usual way to distinguish different releases in the same code base is to make branches for them. So what you're really asking is "is conditional compilation better for releases than branching?". You might want to include that term into your question title. Commented Jan 26, 2015 at 10:30
  • 1
    You can find examples of this in pretty much any Lua module written in C intended to work with both Lua 5.1 and 5.2.
    – Hey
    Commented Jan 26, 2015 at 10:52
  • Hey: isn't that more a single version and binary of the module intended to plug into two different environments?
    – michaeljt
    Commented Jan 26, 2015 at 11:35
  • What do you mean by "different major versions"? Do you mean that both the 1.x and 2.x releases are under active maintenance, or that the user can choose different versions of a software product with different feature sets? Commented Jan 26, 2015 at 11:37

1 Answer 1

1

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
  • Thank you. I will wait for a bit before accepting this in case other people answer. Unfortunately my reputation on "programmers" is not yet high enough to up-vote this. I'm not quite sure I follow the last bit though about reverting the version number for a backwards-compatible change.
    – michaeljt
    Commented Jan 27, 2015 at 8:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.