Back and Forth

When changing software versions we obviously need to consider compatibility. However the implications of this simple statement are not as obvious as they seem.

From the point of view of a user of the new version:

• we add functionality, or
• we change existing functionality, or
• we remove functionality

However this is not the only point of view! Our change may affect some service/infrastructure/data format which is shared with other users. If we change that, what happens for those who (inevitably) do not upgrade?

This situation occurs continually in both directions for Baserock with changes to morph and changes to definitions. Both pieces change frequently. Some times they are changed together, but mostly they change independently. We modify/increase/deprecate morph functionality, update existing definitions and add new ones.

For extra fun, we change systems, on which users run (versions of) morph and (versions of) definitions.

WIP

Forward compatibility: user's old version still works with the new service/infrastructure/data

• old morph continues to work with new definitions (A)
• and new morph works with new definitions (B)

Backward compatibility: new version still works with the old service/infrastructure/data/

• old morph continues to work with old definitions (C)
• new morph continues to work with old definitions (D)

Most of the changes so far have been made without breaking compatibility, but ultimately the cost of this increased complexity in the code (trying to deal with all prior syntaxes).

Somehow we need to maximise usefulness. I (PS) believe that

• tooling should warn, rather than stopping by default
• we should aim for both forward and backward compatibility by default

but i can't prove it... and then someone reminded me about Karnaugh maps, which I think may help us define the space better..